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rVALUATION 


An  objective  of  RADC  TP0-R5A,  Software  Cost  Reduction,  is  the 
exploration  and  development  of  novel  software  tools  and  procedures 
which  enhance  the  IJSAF  software  development  process.  Tools  are 
hardware/software  devices  which  enable  a human  to  bring  greater 
leverage  upon  software  production  and  quality  assurance  processes. 
Procedures  are  uniform  guidelines  which  assist  in  the  unambiguous 
specification  and  development  of  desired  software  products. 

This  effort  has  resulted  in  the  development  of  a new  procedure 
for  writing  computer  programs  that  are  consistent  with  the  functional 
specification  of  the  program.  The  procedure  directly  supports 
requirements  traceability  and  test  case  data  generation.  The 
resulting  programs  contain  no  functional  redundancies  (non-executable 
statements),  and  are  easy  to  read  and  comprehend.  The  concepts  can 
also  be  applied  to  existing  software  to  eliminate  non-executable 
statements  and  improve  execution  performance. 

The  Functional  Programming  methodology  was  developed  and 
demonstrated  using  isolated  computer  programs.  Application 
on  a large  software  system  development  will  be  required  in  order  to 
nrove  the  actual  effectiveness  of  the  methodology, 

DONALD  ROBFRTS 
'’rojcct  lingineer 
Software  Sciences  Section 
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1.0  INTRODUCTION  AND  SUMMARY 


Functional  Progranming  (FP)  is  both  a theory  of  programming  and  a 
method  of  programming  derived  from  the  theory.  The  theory  provides  a 
conceptual  framework  for  thinking  about  programs  and  analytical  tools 
usable  in  analyzing  programs  and  in  writing  programs,  whatever  programming 
method  is  used.  The  theory  does,  however,  suggest  a method  of  programming 
described  in  this  document  and  called  the  "FP  method".  Both  the  theory  and 
the  method  are  evolving  as  they  are  used  and  problems  encountered  are 
solved.  FP  has  potential  for  improving  the  reliability,  maintainability, 
and  performance  of  programs. 

1.1  Overview 

FP  theory  is  based  on  the  formal  model  of  programs  in  the  SEMANOL^ 
system.  It  is  concerned  with  questions,  such  as:  What  is  a program? 

What  is  execution  of  a program?  How  are  programs  structured?  What  are 
the  relations  among  the  structural  elements  of  a program?  What  is  a 
functional  requirement  on  a program?  What  is  a formal  specification  of  a 
program?  l-rhat  is  a functional  capability  of  a program?  What  is  a correct 
program?  ^Jhat  inference  concerning  correctness  of  a program  can  be  made 
from  correct  execution  of  a test  case?  The  theory  provides  precise  answers 
to  these  questions. 

The  FP  method  involves  viewing  (and  partitioning)  the  total  set  of 
inputs  (i.e.,  the  input  domain)  to  a program  as  a number  of  distinct  subsets 
associated  with  program  logical  structures  and  with  functional  requirements. 
The  partitioning  and  association: 

• provide  traceability  of  functional  requirements  to  structural 
elements  of  the  program, 

• simplify  the  control  structure  of  a program  to  eliminate  non- 
executable (phantom)  paths,  functional  redundancies,  and 
unnecessary  executions, 

• support  development  of  test  cases  to  demonstrate  satisfaction 
of  requirements, 

• provide  a description  of  the  program  usable  in  solving  problems 
encountered  in  maintenance, 

• provide  a method  of  constructing  a program  from  the  specification 
of  its  functional  requirements,  and 
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• provide  a method  for  performance  improvement  by  eliminating 
unnecessary  processing. 

A program  written  using  F?  Is  called  a "functional  program". 

Because  Its  structure  Is  simpler,  more  visible,  and  more  directly  traceable 
to  functional  requirements  than  Is  the  structure  of  conventional  programs, 
a functional  program  Is  easier  to  read  and  understand.  The  Increased  struc- 
tural visibility  also  enables  the  programmer  to  detect,  analyze,  and 
correct  many  errors  as  he  Is  writing  the  program,  resulting  In  fewer  errors 
In  the  developed  program.  Because  test  cases  to  demonstrate  satisfaction 
of  a functional  requirement  can  be  constructed  by  merely  selecting  Inputs 
from  the  Input  domain  partition  associated  with  that  requirement,  testing 
becomes  substantially  simpler. 

1.2  S"™nary 

Studies  have  shown  that  much  of  the  apparent  complexity  of  programs 
Is  due  to  the  presence  of  phantom  paths  and  functional  redundancies  (logic 
paths  that  compute  the  same  function) . By  eliminating  them,  FP  produces 
programs  having  simpler  structure  - fewer  paths  and  executable  statements. 
The  presence  of  loops,  usually  regarded  as  the  source  of  much  complexity. 

Is  treated  In  terms  of  sets  of  execution  sequences, and  association  of  each 
such  set  with  an  input  domain  partition  and  functional  requirement.  The 
partitioning  of  the  Input  domain  also  aids  In  the  analysis  of  program 
usage  problems  and  suggests  ways  to  eliminate  some  of  them. 

The  simpler  structure  and  resulting  fewer  executable  statements  In  a 
functional  program  may  reduce  the  program's  use  of  computing  resources  - 
storage  and  execution  time.  Additionally,  the  association  of  input  domain 
partitions  with  program  logical  structures  can  Identify  statements  executed 
for  inputs  from  a given  partition  but  not  needed  to  compute  the  output  for 
that  partition.  Rearrangement  of  the  statements  so  that  processing  is 
performed  for  each  partition  only  if  needed  can  reduce  processing  time  for 
the  affected  partitions. 

FP  can  also  be  used  to  analyze  existing  programs.  It  derives  from 
the  program  text  a complete  description  of  the  program  - what  It  does, 
now  it  executes,  and  Its  response  to  any  input  - in  terms  of  the  input 
domain  partitions  and  their  associated  logical  structures  and  functional 
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requirements.  FP  analysis  can  identify  problems  in  a program  and  indicate 
how  to  correct  then,  thereby  improving  the  reliability  of  a program.  I 
also  provides  data  enabling  the  rewriting  of  the  program,  with  little 
effort,  as  a much  simpler  functional  program  having  no  phantom  paths  and  in 
some  cases,  fewer  executable  statements. 

The  FP  description  of  a program,  derived  from  FP  analysis  of  the 
program  or  from  the  process  of  writing  a functional  program,  can  be  used 
by  a maintenance  programmer  to  solve  problems  occurring  in  the  operational 
use  of  the  program.  It  enables  him  to  relate  the  problem  to  specific 
structural  elements,  functional  requirement,  and  input  domain  partition. 

He  can  then  more  easily  determine  the  source  of  the  problem  and  how  to 
change  the  program  in  a way  that  ensures  that  the  change  satisfies  the 
functional  requirement. 

Many  functional  programs  are  structured  programs;  however,  FP  analysis 
of  existing  programs  has  shown  that  some  structured  programs  have  unnecess- 
arily complicated  structures.  It  shows  how  to  simplify  those  Structures  and, 
in  many  cases,  obtain  a structured  functional  program.  It  has  also  shown 
that,  in  some  cases,  a structured  program  does  not  have  the  simplest 
structure. 

FP  theory  does  not  depend  on  the  programming  language  used,  but 
details  of  the  FP  method  can  be  language  dependent.  FP  is  applicable  to 
both  high  level  language  programs  and  assembly  language  programs. 

In  this  report  we  have  provided  a detailed  definition  and  description 
of  F?  and  have  incorporated  numerous  examples  wherever  necessary  to  clarify 
important  FP  principles  and  {Remonstrate  the  intended  application  of  FP 
techniques. 

FP  theory  is  described  in  section  2,  FP  analysis  in  section  3, 
writing  of  functional  programs  in  section  4,  and  testing  functional 
programs  in  section  5.  Studies  performed  on  the  impact  of  functional  pro- 
gramming on  programming  language  requirements,  software  reliability,  and 
maintenance  are  reported  in  section  6.  Section  7 discusses  system  level 
functional  programming  and  section  8 contains  preliminary  specifications  on 
two  tools  to  support  functional  programming.  Section  9 presents 
conclusions  and  recommendations  and  section  10  lists  references  and  related 
publications . 
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2.0  FUNCTIONAL  PROGRAMMING  DEFINITION  AND  DESCRIPTION 


FP  theory  is  based  on  the  formal  model  of  a program  given  in  the 
SEMANOL  system  (section  2.1).  The  theoretical  concepts  in  the  SEMANOL 
system  are  extended  to  the  structural  elements  of  a program  (section  2.2). 
The  distinction  between  functional  program  requirements  and  functional 
program  capabilities  is  discussed  (section  2.3).  Notation  for  describing 
program  structure  is  developed  (section  2.4);  the  concept  of  phantom  paths 
is  discussed  (section  2.5);  input  domain  partitions  are  defined  (section 
2.6);  and  functional  programs  are  defined  (section  2.7).  The  examples 
used  here  and  in  subsequent  sections  (l.e.,  Routines  A,  B,  and  C)  are 
actual  routines  that  were  developed  for  a very  large  scale  real-time  sys- 
tem. 

2.1  The  SEMANOL  Model  of  a Program 

2 

The  semantic  theory  of  the  SEMANOL  system  provides  the  following 
definition  of  a program: 

• A progr^  p specifies  a computable  function  F on  the  set  E of 
inputs  specified  by  the  input  expressions  in  the  program. 

The  set  E,  the  input  domain  of  the  program,  is  composed  of  members  E^,  each 
member  being  a set  of  input  values  for  an  execution  of  p. 

E » {E^;  i»i,2,  . . . , N} 

The  input  values  composing  each  E^  include  all  the  values  necessary  to 
cause  execution  of  p,  including  those  saved,  if  any,  from  a previous 
execution  of  p.  E Identifies  all  the  computations  program  p can  make: 

• Each  E^in  E corresponds  to  a possible  execution  of  p. 

• Each  actual  ercecution  of  p is  initiated  by  an  input  from  E. 

The  number  N of  members  in  the  set  E is  finite, although  perhaps  very  large, 
for  all  programs  in  which  the  number  of  input  variables  and  their  ranges 
are  finite.  The  function  F is  a rule  which  assigns  to  each  E^  in  E a 
value,  called  the  "function  value"  and  denoted  by  F(E^),  chosen  from  a 
sec  called  the  "range"  of  F. 
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The  definition  of  a prograc  is  fomallzed  through  a semantic  operator 
which,  applied  to  a program  p and  an  input  E^,  prescribes  the  executx.  n 
of  p to  produce  as  its  output  the  function  value  F(E^): 

«(p,E^)  - F(E^) 

E is  the  domain  of  F - i.e.,  the  set  on  which  F is  defined. 

The  correct  output  of  an  execution  of  p with  input  E^  is  F(E^),  the 
desired  function  value.  An  execution  of  p which  does  not  produce  as  its 

A 

output  F(E^)  is  called  an  "execution  failure".  It  can  result  in: 

• incorrect  output;  $(p,E^)  ■ F(E^)  ^ F(E^) 

• premature  termination  of  execution, 

• failure  to  terminate  as  in  an  endless  loop. 

Since  an  endless  loop  does  not  compute  a function  value,  code  containing 
one  is  not  only  incorrect,  it  is  an  "illegal"  program.  Some  programs 
include  apparent  endless  loops  used  to  use  up  time  until  an  interrupt  is 
initiated  by  ari  operator  or  some  external  signal.  In  FP  theory,  such  an 
interrupt  is  an  input  to  the  program  and  should  be  included  in  the  analysis 
of  the  program. 

A "correct"  program  is  one  for  which  all  executions  produce  correct 
output : 

• For  all  E^  in  E,  't(p,E^)  = F(E^) 

This  definition  of  a correct  program  can  be  extended  to  allow  a tolerance 
in  execution  output: 

• For  all  E^  in  E,  l<5(p,E^)  - F(E^)  | < e 
2.2  Extension  to  Program  Structural  Elements 


When  program  p executes  with  input  E^,  the  execution  proceeds  through 
a specific  code  sequence,  called  an  executable  logic  path,  Lj . The  same  code 
sequence  - i.e.,  the  executable  logic  path  - nay  be  caused  to  execute  by 

The  set  of  all  inputs  which  cause  to  be  executed  is  denoted 


other  inputs. 


by  G 


J* 


Gj  is  a subset  of  E such  that: 


• execution  of  p with  in  executes  Lj , and 

• if  causes  execution  of  , it  is  in  . 

Execution  of  p with  an  E^  a member  of  E but  not  a member  of  G^  causes 
execution  of  another  logic  path,  say  with  . 

All  inputs  E^  in  E cause  execution  of  some  logic  path;  therefore 
each  E^  is  a member  of  some  G^  and  is  associated  with  a logic  path  . 
(There  can  be  code  sequences  in  a program  which  cannot  be  executed  by 
any  input.)  Thus  the  union  of  all  the  subsets  G^  is  the  set  E: 


The  subsets  G^  are  disjoint,  for  no  E,.  can  cause  execution  of  more  than  one 
logic  path. 


G^flGj^  - ij)  for  j k (i>:  null  set) 

The  G^  therefore  partition  E. 

Since  the  code  sequence  is  itself  a program,  it  may,  in  accordance 
with  the  formal  definition  of  a program,  be  interpreted  as  specifying  a 
computable  function  on  G^ : 

«(Lj,E^)  - Fj(E^)  for  E^  in  G^ 

The  "total" function  F,  specified  by  p,  may  therefore  be  represented 
by  the  collection  of  functions  F^ , each  F^  being  defined  on  its  domain  G^ . 

In  terms  of  the  and  F^ , a program  may  be  represented  as: 

• For  all  j in  l^^n  (If  E^is  in  Gj , Compute  Fj(E^)) 

In  actual  programs,  determination  of  the  G^  of  which  E^  is  a member 
is  accomplished  by  evaluation  of  a sequence  of  branch  expressions.  Evaluation 
of  the  sequence  may  include  transforming  some  of  the  values  in  E^  to 
a fora  such  that  the  branch  expressions  are  simpler;  e.g.,  the  variables 
XI  and  X2  may  be  transformed  into  polar  coordinates  before  a particular 
branch  expression  is  evaluated. 
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2.3  Functional  Requirenents  and  Functional  Caoabll j g-tes 


Partitioning  of  F,  the  function  p is  intended  to  compute,  and  its 

A A A 

domain  E into  the  set  of  pairs  (G  F ) defines  a set  of  "functional  require- 

J ’ J 

ments"  on  p.  (In  addition  to  functional  requirements,  a program  may  have 

performance  requirements,  reliability  requirements,  maintenance  requirements, 

etc.)  The  partitioning  of  F,  the  function  p actually  computes,  and  its 

domain  E into  the  set  of  pairs  (G  F ) defines  the  "functional  capabilities" 

J • j 

of  p. 

The  objective  of  reliable  software  development  generally  is  to  produce 
the  program  such  that  its  functional  capabilities  are  the  same  as  its  func- 
tional requirements.  Similarly,  the  objective  of  software  verification  is  to 
verify  that  the  functional  capabilities  are  the  same  as  its  functional  re- 
quirements - i.e.,  to  verify  that,  for  all  j: 


and 


F. 

2 


Problems  arise  when  G G . and/or  the  F F . In  addition  to  the 

3 3 3 a3 

obvious  problem  of  an  execution  failure,  (E^)  f F^(E^),  there  are  other 


■j 


problems  analyzable  in  terms  of  the  (G  F ) and  (G  F.).  One  common 

3 > 3 3 1 3 

problem  is  that  a program  may  have  functional  capabilities  not  specified 
in  its  functional  requirements;  e.g.,  in  addition  to  functional  capabilities 
(Gi,  (G21  F2) , ...»  (G^,  F^)  corresponding  to  functional  requirement.s 

(Gn  F^) , (G2,  F2) , ...»  (G^,  F^) , a program  may  have  functional  capabili- 

^^n+l,J'n+l^’  ^‘^n+2'  ^2^’  ^^m’  ^m^  corresponding  to  any 

stated  functional  requirements.  These  "hidden  capabilities"  are  the  source 
of  many  usage  problems.  This  commonly  arises  when  the  G^  do  not  collect- 
ively cover  all  of  the  variable  ranges  defined  by  the  computer  word  size. 

A user  not  understanding  the  limitations  of  a program  may  then  select  an 


input  fron  one  of  the  G^_^j'3  and  obtain  as  output  a function  value 
not  interpretablfe  in  terms  of  what  he  expected  the  program  to  compute. 

Another  type  of  usage  problem  arises  when  the  required  functions 

A A 

Fj  are  not  clearly  associated  with  the  on  which  they  are  defined.  A 
user  wanting  to  perform  a function  may  select  an  input  from  G^^,  with 
kfi j , and  when  he  obtains  the  output  instead  of  the  expected  Fj(E^), 

he  ascribes  the  problem  to  an  error  in  the  program. 

FP  methodology  for  writing  programs  (section  4)  involves  explicit 

A A 

definition  of  the  functional  requirements  (G^ , F^)  and  provides  a method 
for  designing  the  program  so  that  it  contains  only  the  functional  capabili- 

A A 

ties  (Gj , Fj)  corresponding  to  the  (G^ , F^)  and  no  others. 

2.4  FP  Notation 


Functional  analysis  of  programs  is  aided  by  introducing  a notation  for 
representing  program  structure  in  more  detail.  The  structural  elements 
at  the  level  below  the  logic  path  are: 

• branch  expression  - an  expression  which  when  evaluated  determines 
the  execution  sequence,  such  as  a boolean  expression  in  a logical 
IF  statement  or  an  arithmetic  ertpression  in  an  arithmetic  IF 
statement. 

• in-line  code  segment  - a sequence  of  executable  expressions  not 
containing  any  branch  expressions,  such  that,  if  one  of  the 
executable  expressions  is  executed,  all  of  them  will  be  executed. 

In-line  code  segments  will  be  denoted  by  the  symbol  S^,  with  the  value  of 
the  subscript  i denoting  the  numerical  order  of  a segment  in  the  program. 
Branch  expressions  are  denoted  by  S^,  with  the  subscript  j taking  on 
numerical  values  denoting  the  numerical  order  of  the  branch  expression  in 
the  program.  The  superscript  k identifies  Sj  as  representing  a branch  ex- 
pression, and  is  also  a variable  denoting  the  value  resultirj,  from  an 
evaluation  of  the  branch  expression.  If  is  a boolean  expression,  such 
as  I-IN.EQ.O,  it  may  be  evaluated  TRUE,  denoted  by  t,  or  FALSE,  denoted  by  f; 
e.g.,  Sj  denotes  branch  expression  evaluated  TRUE.  If  is  an  expression 
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in  a FORIBAN  arithaeclc  IF  stacement,  it  nay  be  evaluated  to  be  less  than 
0,  denoted  by  it  may  be  evaluated  to  be-equal  to  0,  denoted  by  0;  or 


Sj  denotes 


it  may  be  evaluated  to  be  greater  than  0,  denoted  bv  +;  l.e. 

k ' k 

branch  expression  evaluated  to  be  greater  than  0. 

arithmetic  expression  in  a FORTRAN  computed  GOTO  statement,  k denotes  the 

3 k 

integer  result  of  its  evaluation;  i.e.,  denotes  branch  expression 
evaluated  to  be  3. 


As  an  example  of  the  use  of  the  notation,  consider  the  following 
FORTRA^l  program,  called  Routine  A: 

IF(Gi;.NE.0)  GOTO  10 

$2  IF(CN.LT.CT)  GOTO  5 

IE  - 1 
GOTO  25 

$2  5 IE  - 0 

GOTO  25 

10  IF(CN.LT.TR)  GOTO  20 
S3  IE  - 1 

GOTO  25 

S,  20  IE  - 0 

4 

25  IF(IE.NE.l)  GOTO  40 
S,  JE  =■  JE  + 1 

j 

KI  - JD 

KI  - 2 

KR  - 3 

K3  - JA 

KE  - JB 

JV  - JV  + KI  + 1 

KG  - 1 

S,  40  RETURN 
o 

END 

FIGURE  2-1.  FORTRAN  Subroutine  A 
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Routine  A has  20  executable  statements,  6 segments,  and  4 branch  expressions. 
The  branch  expressions  Sj  are  defined  to  be  the  expressions  evaluated 
within  the  IF  statements  and  the  segments  are  defined  not  including 
any  GOTO  statements  at  their  termination;  thus,  for  Routine  A,  the  branch 
expressions  and  segments  are: 


Branch  Expressions 
S 
S 
S 
S 


Segments 


’1* 

,k 

’2* 

*3* 

^4- 


GN.NE.O 

IE  - 1 

JE  - JE  + 
KI  = JD 

1 

CN.LT.CT 

^2* 

IE  - 0 

KM  - 2 

KR  - 3 

cn.lt.tr 

S3: 

IE  - 1 

KB  - JA 

KE  - JB 

lE.NE.l 

S4! 

IE  - 0 

JV  - JV  + 
KG  - 1 

KI  1 

^6^ 

RETURN 

In  terns  of  this  notation.  Routine  A can  be  vnritten  as  shown  in  Fig.  2-2. 


IF  GOTO 

IF  $2  GOTO  $2 

^1 

GOTO 

^2 

GOTO 

IF  GOTO  S, 

3 4 

GOTO 

^4 

IF  GOTO  S, 

4 6 

^5 

^6 

Figure  2-2.  Routine  A in  F?  Notation 
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Routine  A in  FP  notation  is  more  compact  chan  the  original  program  and 
its  structure  is  shown  more  vividly.  In  this  notation,  "IF"  denotes  th;  “ 
the  branch  expression  following  it  is  to  be  evaluated,  with  the  results 
of  Che  evaluation  used  to  determine  the  branch  to  be  taken.  "GOTO"  denotes 
a transfer  of  the  execution  sequence  to  the  branch  expression  or  segment 
named  following  the  GOTO.  From  the  FP  notation  form  of  a program,  a 
diagram  showing  the  logical  structure  of  the  program  can  be  prepared 
directly.  Such  a diagram  for  Routine  A is  presented  in  Fig.  2-3. 


Figure  2-3. 


Structure  of  Routine  A 


In  the  diagran,  the  left  hand  branch  from  the  lower  side  of  a circle 

k f 

surrounding  a branch  expression  S denotes  a FALSE  evaluation  S.  and  the 
right  hand  branch  denotes  a TRUE  evaluation  Sj . By  convention,  the  flow  of 
execution  is  downward,  so  arrows  denoting  execution  flow  direction  are  not 


In  terms  of  the  FP  notation,  the  3 potential  execution  sequences  are: 


S 


2.  5 Phantom  Paths 


Although  there  are  3 apparent  logic  paths  through  Routine  A,  4 of 

them  are  not  executable.  They  arise  because  the  evaluation  of  branch 

expression  S,  is  dependent  on  prior  assignments  of  value  to  the 
^ k 

variable  IE  in  segments  S2»  S^,  and  S^.  branches  on  whether  IE  has 

the  value  0 or  1.  Since  S, , S~,  S-,  and  S,  set  IE  to  1,  0,  1,  0 respectively, 
ff 

tne  sequence  S^  S2  S^  must  result  in  S^,  the  sequence  S^  S2  S2  must  result 
in  S^,  the  sequence  S^  S^  S^  must  result  in  S^,  and  the  sequence  S^  S^ 
must  result  in  S^.  Only  the  following  logic  paths  are  executable: 


^ S^  S S^  s 
1 ^2  ^1  ^4  ^5 


^1  ^2  ^2  ^4  ^6 

Si  S3  S3  s-  S5 

^4  -4'  2, 
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The  renaining  4 code  sequences  are  not  executable.  They  are  therefore 
"phantom  paths". 

In  the  case  of  Routine  A,  one-half  of  the  potential  logic  paths  are 
e:4ecutable  and  one-half  are  phantom  paths.  Some  programs  have  more  phantom 
paths  than  executable  paths.  The  actual  structure  of  a program  can  be 
concealed  in  a web  of  phantom  paths  obscuring  the  executable  logic  paths 
so  that  they  cannot  be  readily  seen  by  reading  the  program  text. 

Because  of  the  existence  of  phantom  paths,  the  text  of  a program 
does  not  continually  cue  the  programmer  on  the  actual  structure  of  the 
program  as  he  writes  it.  He  has  to  keep  a picture  of  the  structure  entire- 
ly in  his  mind.  If  the  program  is  more  than  a few  statements  long,  this  may 
be  quite  difficult.  The  resulting  structural  confusion  may  lead  to  pro- 
grammer errors.  Such  errors,  when  made,  cannot  be  easily  detected  by 
scanning  the  program  text;  they  are  found  only  through  extensive  and  costly 
debugging  and  testing. 

2.6  Input  Domain  Partitions 

2.6.1  Determination  of  Input  Domain  Partitions 


Partitioning  of  the  input  domain  into  subsets,  Gj  is  determined  by 
constraints  on  the  v'alues  of  the  input  variables  imposed  by  the  branch  ex- 
pression evaluations  selecting  the  logic  path  Lj . Each  input  variable  ran- 
ges over  a set  of  values  specified  explicitly  in  p by  a data  declaration  or 
implicitly  by  a convention  in  the  programming  language.  A branch  expression 
partitions  the  range  set  of  a variable  into  two  or  more  subsets.  As  a 
logic  path  is  executed  each  successive  evaluation  of  a branch  expression 
constrains  the  range  of  one  or  more  input  variables.  The  net  effect  of  all 


of  the  branch  expression  evaluations  for  logic  path  is  to  constrain  the 
values  of  the  input  variables  to  lie  within  Gj . Some  of  the  input  variables 
may  not  have  their  ranges  constrained  by  the  branch  expression  evaluations. 


Also,  some  of  the  input  variables  may  not  enter  into  the  calculations  in  Lj . 
Thus  the  number  of  variables  to  which  values  must  be  assigned  may  differ 


from  logic  path  to  logic  path. 


Determination  of  the  Gj  may  be  illustrated  by  constructing  the  input 
domain  partitions  for  Routine  A.  Routine  A has  9 input  variables  - GN,  CtJ, 
CT,  TR,  JE,  JD,  JA,  J3,  JV  - to  which  values  are  assigned  prior  to  entering 
the  routine.  It  has  no  data  declarations,  so  the  range  sets  of  the  input 
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variables  are  deterained  by  the  convention  in  FORTRAN  that  variables 
beginning  with  the  letters,  I,  J,  K,  L,  M,  or  N are  integer  variables 
and  variables  beginning  with  any  other  letter  are  real  variables. 
Thus: 


• GN,  C:i,  CT,  and  TR  are  real  variables. 

• JE,  JD,  JA,  JB,  and  JV  are  integer  variables. 


The  ranges  of  these  variables  are  determined  by  the  computer  word  length. 

The  partitioning  of  the  ranges  of  these  variables  is  determined  by 
k Ic  k 

the  branch  expressions  S2,  and 

• partitions  the  range  sec  of  GN  into  the  value  0 and  all  other 
possible  values. 

• $2  partitions  Che  range  sec  of  C'l  into  values  less  Chan  Che  value 
of  CT  and  values  greater  chan  or  equal  to  the  value  of  CT. 


Sj  partitions  the  range  set  of  CU  into  values  less  than  the 
value  of  TR  and  values  greater  than  or  equal  to  the  value  of  TR. 


acts  on  the  internal  variable  IE  and  has  no  partitioning  effect  on  Che 
k.  h k 

input  variables.  S^,  and  act  only  on  Che  variables  GN,  CN,  CT,  and 

TR.  They  have  no  partitioning  effect  cn  JE,  JD,  JA,  JB,  and  JV . 


2.^.2  Specification  of  Input  Domain  Partitions 

The  input  domain  partitions  may  be  specified  by  listing  the  branch 
expression  evaluations  and  any  variables  whose  range  sets  are  not 
partitioned: 


• 

: GN  - 

0, 

CN^CT, 

JE. 

JD, 

JA, 

JB, 

JV 

• 

‘^2 

: GN  - 

0. 

CN<CT 

• 

: GN 

0, 

CN^TR, 

JE, 

JD. 

JA, 

JB, 

JV 

• 

^4 

: GN  1* 

0. 

CN<TR 

Mote  that  although  there  are  9 input  variables,  only  8 are  included  in 
Gj^,  3 in  G2,  8 in  G^,  and  3 in  G^.  Thus  each  E^  in  G^  is  a set  of  8 values; 
each  in  G2  is  a sec  of  3 values;  each  in  G^  is  a set  of  8 values; 
and  each  E^  in  G^  is  a set  of  3 values.  The  complete  input  domain  may  be 
constructed  by  forming  the  union  of  its  partitions: 


E - G,  U G,  U G,  U G, 

X « J «4 

The  functions  corresponding  to  each  of  the  G^  are: 
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■ 


^5  ^6 


JE  =«  JE  + 1 
K.I  - JD 
KM  - 2 
KR  =■  3 
KB  - JA 
KE  = JB 

JV  = JV  + KI  + 1 

KG  = 1 

RETURN 


i.e. , updates  certain  values  in  a data  base. 


Each  computed  value  of  is  a combination  of  the  values  assigned  to 
the  variables  JE,  KI , KM,  KR,  KB,  BCE,  JV,  and  KG  at  the  end  of  execution  of 
Routine  A.  It  is, therefore,  an  8-tuple  having  as  its  elements  the  values 
assigned  to  these  variables.  Three  of  these  elements  - viz.,  the  elements 
associated  with  ICM,  KR,  and  KG  - are  restricted  to  a single  value.  The  re- 
maining 5 elements  can  individually  range  over  the  set  of  integers  fitting 
within  one  word  length.  The  range  set  of  F^  is  the  set  of  these  8-tuples. 

The  mapping  from  G^^  to  this  output  set  of  8-tuples  is  defined  by  the  equations 
corresponding  to  the  assignment  statements  in  S^. 

• F^:  : RETURN:  uomputes  no  output  values; 

i.e.,  F2  does  not  update  the  data  base. 

Since  F,  computes  no  value,  the  range  set  of  F^  is  a set  containing  no 


values  - viz. 


the  null  sec  9.  F^  then  maps  the  set  G2  into  9. 


JE  - JE  + 1 
KI  - JD 
KM  - 2 
KR  - 3 
KB  - JA 
KE  = JB 

JV  - JV  + KI  + 1 

KG  =■  1 

RETURN 


F..  updates  the  data  base. 


• ^4'  ^6=  RETURN: no  update 

Mote  chat  F,  = F^  and  F.,  =•  F_,  . Roi 


Routine  A contains  functional  redundancies 


of  the  Kind  treated  in  the  next  section. 
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An  alternative  technique  for  specifying  the  input  domain  partitions  is 
via  a graphical  representation  (Figure  2-4).  This  type  of  illustration 
supports  the  analyst  in  assuring  that  all  significant  values  of  branch 
variables  have  been  considered.  It  also  helps  in  the  derivation  of  input 
values  for  test  cases.  This  technique  has  proven  to  be  a valuable  tool  in 
the  functional  design  (or  redesign)  of  large  programs.  If  desired,  the 
functions  (Fj)  may  also  be  included  as  shown  in  Sections  4.3  and  4.4,  thus 
providing  a concise  illustration  of  the  desired  functional  capabilities. 


GN  - 0 

GN  0 

CM  2 CT 

CN  < CT 

CN  * TR 

CN  < TR 

G2  G3  G4 


Figure  2-4.  Graphical  Representation  of  Input  Domain  Partitions 


2 . 7 Functional  Programs 


Can  programs  be  written  so  they  contain  no  phantom  paths?  Can  the 
functional  redundancies  be  eliminated?  Based  on  the  preceding  analysis 
into  the  G^  and  F ^ , Routine  A can  be  rewritten  without  functional 
redundancies  and  with  no  phantom  paths.  First  combine  the  partitions  of 
the  redundant  functions: 
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• ^2  ■ *^2  ^ ^^4 

Then  construct  the  branch  expressions  corresponding  to  the  new  partitions: 

• G|:  (GN.EQ.O) .AND. (CN.GE.CT) .OR.  : S^' 

(GN.NE.O) .AND. (CN.GE.TR) 

• g;:  (GN.EQ.O) .and. (CN.lt. CT) .or.  : 

(GN.NE.O) .AND. (CN.LT.TR) 


Since  Gj^  and  G!^  are  disjoint  sets  and  are  complements  of  each  other 
relative  to  E,  only  one  of  the  new  branch  expressions  is  needed.  Routine  A 
may  therefore  be  written,  in  F?  notation: 

IF  S,'  GOTO  S, 

2 6 


“6 

This  new  form  of  the  program  has  only  2 paths,  both  executable,  correspond- 
ing to  the  2 distinct  functions.  Substituting  the  FORTRAN  expressions  for 

, S.,  and  S,  provides  FORTRAN  code  for  the  revised  version  of  the  Routine  A 

» 3 0 

as  shown  in  Figure  2-5. 


IF((GN.EQ.O)  .A:iD.(CN.LT.CT)  .OR. 

(GN.NE.O) .AND. (CN.LT.TR))  GOTO  10 

JE  = JE  + 1 
KI  «•  JD 
KM  = 2 
KR  *>  3 
KB  =■  JA 
KE  “ J3 

JV  - JV  + KI  + 1 
.KG  - 1 
10  RETLTIN 
END 


Figure  2-5.  Revised  Routine  A 
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The  original  version  of  Routine  A had  8 apparent  paths,  4 of  which  were 
executable,  and  20  executable  statements.  The  revised  version  has  2 logic 
paths,  both  executable,  and  10  executable  statements.  It  therefore  has  a 
simpler  structure  and  less  code;  however,  it  has  introduced  a complication 
in  that  it  contains  a compound  Boolean  expression. 


The  final  version  is  called  a "functional  program",  because  its 
structure  is  explicitly  related  to  the  functions  Fj  performed  by  the  pro- 
gram and  their  input  domain  partitions  Gj . More  generally,  a functional 
program  has  no  phantom  paths  and  the  functions  F^  and  input  domain  parti- 
tions Gj  corresponding  to  each  of  its  logic  paths  have  been  explicitly 
defined;  i.e.,  specifications  for  them  have  been  written  down,  so  they  are 
explicitly  known  and  not  merely  intuitive  concepts  in  the  programmer's  mind. 


Routines  A and  the  other  routines.  Routine  B and  Routine  C,  used  in 
this  report  as  examples  explaining  FP  concepts,  are  actual  routines  from  a 
real  time  software  project.  These  routines,  written  in  FORTRAN,  were 
required  to  be  structured  using  only  certain  specified  control  structures, 
modelling  the  structured  programming  control  structures  of  IF  THEN  ELSE, 

DO  WHILE,  etc.  in  terms  of  specified  groups  of  FORTRAN  IF  statements  and 
GOTO  statements.  Both  the  original  and  FP  version  of  Routine  A are 
"structured"  in  accordance  with  this  definition. 
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3.0  FUNCTIONAL  PROGRAMMING  ANALYSIS 

Functional  programming  analysis  is  the  application  of  the  basic 
ideas  of  functional  programming  to  the  analysis  of  existing  programs.  It 
derives  from  the  program  text  a complete  description  of  the  program  - 
what  the  program  actually  does,  how  it  executes,  and  its  response  to  any 
input.  It  therefore  is  a technique  for  independent  analysis  of  programs. 
Since  this  independent  analysis  can  identify  problems  in  the  program,  it 
can  contribute  to  improving  the  reliability  of  the  program.  The  description 
of  the  program  can  also  aid  the  maintenance  programmer,  who  generally  was 
not  involved  in  developing  the  program,  in  understanding  the  program, 
analyzing  problems,  and  determining  the  changes  needed  to  solve  the  problems. 
Because  it  partitions  the  input  domain  into  subsets  associated  with  function- 
al requirements,  functional  programming  analysis  can  aid  the  generation  of 
test  cases  to  demonstrate  satisfaction  of  the  functional  requirements.  The 
description  also  provides  data  usable  in  rewriting  the  program  as  a 
functional  program. 

3.1  Functional  Programming  Analysis  Methodology 


Functional  programming  analysis  closely  follows  the  method  used  in 

Section  2 for  analyzing  Routine  A to  illustrate  the  concepts  of  functional 

programming.  The  objective  of  functional  programming  analysis  of  a given 

program  is  to  partition  the  input  domain  E of  that  program  into  subsets 

G.  associated  with  executable  logic  paths  L.  and  to  determine  the  function 

F.  each  L computes.  This  analysis  is  accomplished  by  identifying  in  the 
J J <. 

program  text  the  in-line  code  segments  S.  and  the  branch  expressions  S^, 

k ^ 3 

analyzing  the  evaluations  of  the  to  determine  the  L^ , and  analyzing  the 
Sj  composing  each  L^  to  determine  the  F^ . 

This  analysis  can  be  performed  by  carr'/ing  out  the  following  steps: 
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1.  Identify  the  segaents  and  branch  expressions  Sj  in  the  prograa  text 
by  marking  them  on  the  left  hand  margin  of  the  program  listing. 

2.  Rewrite  the  program  in  FP  notation.  This  provides  a more  compact 
representation  of  the  program,  aiding  further  analysis. 

3.  Construct  a diagram  (such  as  the  one  in  Fig.  2-3)  showing  the 

S^,  the  Sj , and  their  interconnections.  Although  this  step  is  not 
absolutely  necessary,  it  aids  in  visualizing  the  structure  of  the 
program. 

It 

4.  Determine  the  subsets  , using  the  Sj  evaluations  to  specify 
partitioning  of  the  input  variable  ranges,  by  carrying  out  the 
following  substeps: 

a)  identify  the  input  variables  and  their  range  sets. 

b)  analyze,  the  first  branch  expression,  to  determine  its 
partitioning  effect  on  input  variable  ranges. 

c)  successively  analyze  execution  sequences  involving  2,  3,  ... 
branch  expressions,  determining  at  each  stage  the  partitioning 
effect  on  input  variable  ranges. 

d)  on  identifying  a phantom  (non-executable)  sequence,  eliminate  it 
from  further  analysis. 

e)  continue  the  process  until  all  the  executable  sequences  have  been 
defined.  The  corresponding  partitions  on  the  input  variable  ranges 
are  the  . 

5.  Associate  each  G^  with  a sequence  of  S^'s. 

6.  Determine  F from  the  sequence  of  S.  associated  with  G . 

j ^ J 

7.  Construct  E from  the  union  of  the  G^  and  F from  the  F^ . 


Carrying  out  this  procedure  is  relatively  easy  for  small  programs 
("<100  statements).  For  larger  programs,  the  analysis  can  be  made  more 
manageable  if  the  program  contains  subroutines.  The  subroutines  are 
analyzed  first.  The  set  of  inputs  for  each  subroutine  are  then  matched 
with  the  range  of  values  computed  for  each  input  variable  in  the  calling 
routine. 
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3.2  £:{£mp].e  of  FuacClonal  Frograamlng  Analysis 


Application  of  the  functional  pro^tasaiing^^aMlysis  steps,  given  in 
3.1,  is  explained  by  using  them  to  analyze  a F0RTRAil'>o«t4ne , called 
"Routine  B".  The  first  step  in  the  FP  analysis  has  been  c 
marking  Che  and  on  Che  left  hand  margin  of  the  listing  (Figure  3- 


^1 

KF  = ZR 

K - KF  + 1 

U1  - -ZT(2) 

U2  - -ZTO)*ZS(K)  + ZT(7)*ZC(K) 

^1 

U3  - ZT(3)*ZC(K)  + ZT(7)*ZS(K) 

IF  (U3.LT.ZE(K))  GOTO  100 

So 

S2  - U1**2/(U1**2  + U2**2) 

IT  - 1 

IF  (S2.LT.ZA)  GOTO  20 

^3 

IF  (Ul.LT.O)  GOTO  10 

S3 

KF  •»  KF  + 1 

GOTO  50 

S4 

10 

KF  - KF  + 3 

GOTO  50 

20 

IF(U2.LT.O)  GOTO  30 

S5 

IT  - 0 

GOTO  50 

S6 

30 

KF  - KF  + 2 

s^.s, 

50 

IF  (KF.GT.3)  KF  = KF  - 4 

n 

IF  (IT.EQ.O)  GOTO  200 

h 

TL(1)  - 5 

TL(2)  - KF 

GOTO  200 

S9 

100 

TL(1)  - 6 

TL(2)  - KF 

IF  (ZD.EQ.l)  GOTO  200 

SlO 

ZRF  - ZRF  + 1 

ZQ(Z3)  - ZF 

ZV(Z3)  - ZM 

ZS(Z3)  - ZI 

ZDQ(Z3)  - 3 

Z3  = 23  + Z0(Z3)  1 

ZD  - 1 

Sll 

200 

ZFC  - ZR 

•RETURN’  , 

END  1 

Figure 

3-L. 

FCRTR.VI  Subroutine  B i 

! 

* 

Routine  B has  35  executable  statements,  7 branch  expressions,  and  11 
segments. 

The  second  step  is  to  rewrite  the  routine  in  FP  notation,  producing 
the  following  more  compact  representation  shown  in  Figure  3-2, 


IF  GOTO  Sg 
^2 

IF  $2  GOTO 
IF  $2  GOTO 

GOTO  Sj 
S, 

GOTO 

IF  GOTO 

^5  k 
GOTO  Sj 

k 

IF  (Sp  S, 

IF  GOTO  S, , 
Q XI 

^8 

GOTO 

k 

I?  GOTO 


Figure  3-2.  Routine  B in  FP  Notation 

A graphical  representation  of  the  structure  of  Routine  B (Figure  3-3) 
shows  18  apparent  logic  paths. 
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Step  4a  applied  to  Routine  5 finds  all  the  variables  to  which  values 
nust  be  assigned  external  to  the  routine  In  order  for  It  to  execute: 

ZR 

ZT(2),  ZT(3),  ZT(7) 

ZS(K) 

ZC(K) 

ZE(K) 

ZA 

ZD 

ZRF 

Z3 

ZF 

ZN 

ZI 


The  value  of  Input  variable  ZR  Is  converted  In  the  first  executable 
statenent  to  an  Integer  value,  denoted  by  KF.  A constraint  external  to 
the  subroutine  Halts  values  of  ZR  to  O^ZR^S.  Z3  Is  defined  externally 
as  an  Integer  for  use  as  a subscript. 


Seep  4b,  analysis  of  s':  U3.LT.ZE(K),  shows  that  two  of  the  variables 
in  U3  and  K,  the  index  of  ZE(K),  are  not  themselves  input  variables  but 
are  computed  by  code  in  from  input  values  of  the  actual  input  variables 

the  set  of  values  which 


of  ZE(K). 

Sg,  followed  by  evaluation 
of  ZD  into  ZD  “ 1 and 


ZR,  K - KF  + 1 
ZN,  ZI; 

ZR,  K - KF  + 1 


ZR,  ZT(3),  ZT(7),  ZC(K),  and  ZS(K).  partitions 
can  be  assigned  to  U3  in  2 subsets: 

• values  less  than  the  value  of  ZE(K) 

• values  greater  than  or  equal  to  the  value 

TRUE  evaluation  of  S.  transfers  execution  to 
of  Sj,  which  partitions  the  set  of  possible  values 
ZD  # 1.  These  evaluations  define  two  logic  paths: 

• S,  Sj  Sg  S5  S,, 

• 4*  ^1  ^1  ^9  ^7  ^10  ^11 

The  input  domain  partitions  for  these  paths  are: 

• G^:  ZR,  U3  < Ze(K) , ZD  - 1; 

U3  - ZT(3)*ZC(K)  + ZT(7)*ZS(K),  KF  - 

• ZR,  U3  < ZE(K),  ZD  1,  ZRF,  Z3,  ZF, 
U3  - 2T(3)*ZC(K)  + ZT(7)*ZS(K),  KF  - 


• ■ 
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la  the  description  of  the  , the  partitioning  relations  and  any 
unpartitioned  input  variables  are  listed  preceding  the  semicolon.  After 
the  semicolon,  transformations  on  the  input  variables  that  must  be  made 
before  applying  the  partitioning  relations  are  listed. 


FALSE  evaluation  of  transfers  execution  to  S2.  Then  evaluation 
of  s’^tSl.LT.ZA,  followed  by  evaluation  of  S2:U1.LT.0  or  S^:U2.LT.O, 
selects  whether  S^,  S^,  or  is  executed: 


• $2  selects 

• selects  S, 

2 3 4 

• S,  sf  selects  S_ 

2 4 5 

• selects  S, 

2 4 6 

S^,  S^,  and  change  the  value  of  KF,  while  does  not.  Evaluation  of 

S,:KF.GT.3  tests  KF  to  determine  whether  or  not  its  value  is  greater  than  3. 
For  initial  values  of  KF  ^ 3,  execution  of  the  sequence  S-  S-  can  only  result 
in  Sj  being  evaluated  FALSE.  If  an  initial  value  of  KF  > 3 (i.e.,  ZR  > 3) 
is  input,  the  external  constraint  on  ZR  is  violated,  causing  Routine  B to 
compute  something  having  no  physical  significance.  Thus  the  sequence  S-  S^ 
will  not  be  executed  for  all  meaningful  inputs.  Therefore  it  is  a phantom 
sequence.  This  analysis  suggests  that  the  routine  should  include  a test  for 
ZR  > 3 with  an  error  message  in  case  it  is. 

S,:IT.EQ.O  tests  the  value  of  the  internal  flag  IT,  which  is  set  to 

° f k 

the  value  1 by  $2  and  to  the  value  0 by  S^.  Thus  the  sequence  must 

result  in  evaluated  TRUE  and  all  sequences  not  involving  must  result 

in  Sg  evaluated  FALSE.  Accordingly,  the  following  are  phantom  sequences: 

• ^5  ^5  ^6 

• ^3  S5  ^6 

• S3  S5  S7 

• Sj 
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A 


• S4  S, 

• ^6  ^6 

• ^6  ^5  ^6 

These  7 phantom  sequences  plus  the  two  identified  earlier  - S s5  and 

t f 5 5 7 6 

S3  S3  Sg  - indicate  that  9 of  the  18  apparent  paths  of  Routine  B are 

phantom  paths.  The  remaining  9 paths  are  executable. 

Definitions  for  two  of  the  input  domain  partitions,  and  G2,  end 
their  associated  logic  paths,  and  L2,  were  given  previously.  The 
sequences  for  the  7 other  executable  paths  and  their  input  domain  partitions 
are: 

• L3:  $2  S2  Sg  S3  Sj  Sg  Sg  2r,  u3  _>  ZE(K),  S2  <ZA,  U2<0,  K?>1; 

KF  - ZR,  K - KF  + 1, 

U3  . ZT(3)*ZC(K)  + ZT(7)*ZS(K), 

S2  - (U1)^/((U1)^  + (U2)^), 

U1  - -ZT(2) 

U2  — ZT(3)*ZS(K)  + ZT(7)*2C(K) 


• Sj_  S2  S2  Sg  S3  Sg  Sg  S ^ 


ZR,  U3^ZZ(K),  S2<ZA,U2<0,  KF^  1; 
KF,  K,  U3,  S2,  U1  and  U2  as 

defined  in  G, 


• ‘•s'  h =1  =2  =2  =4  ^5  ^6  =11 


G3:  ZR,  U3^ZE(K),  S2<ZA,  UZ^O.KF  s3; 
KF,  K,  U3,  S2,  Ul,  and  U2  as 
defined  in  G, 


Lg:  S^  s;  S2  si  S=  S^  S3=  S^  s|  Sg  S 


, , G,:  ZR,  U3>ZE(K),  S2>ZA,  U1<0,  KF>0; 

li  0 — — 

KF,  K,  U3,  S2,  Ul,  U2  as 
defined  in  G. 


• L^:  Sj_  S^  S,  S2  S3  S^  S3  Sg  Sg 


G^:  ZR,  US^ZECK),  S2^ZA,  UKO,  KF-0; 
KF,  K,  U3,  S2,  Ul,  and  U2  as 
defined  in  G_ 
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A 


I 


-8* 


-g- 


Si  sf  Sj  s'  s'  S3  s;  s,  s'  s,  Sii 


'1  '2  '2  ^3  ®3  's  '11 


8’ 


ZR,  U3^ZE(K),  S2^ZA,  Ul^O,  KF-3; 
KF,  K,  U3,  S2,  Ul,  and  C2  as 
defined  in 

ZR,  U3^ZE(K),  S2^ZA,  Ul^O,  KF<3; 
KE,  K,  U3,  S2,  Ul,  and  U2  as 
defined  In  G^. 


The  segment  sequences  for  each  logic  path  specify  the  functions  Fj . 

The  range  set  of  each  of  the  is  a set  of  n-tuples,  the  value  of  n being 


1 for  Fj,  4 for  F^,  F^,  F^,  F^,  F^,  Fg,  and  F^,  and  11  for  F2.  The  mappings 
Fj  from  the  G^  to  the  range  sets  are  specified  by  the  equations  associated 
with  the  assignment  statements  in  the  segment  sequences  listed  below: 


• 

^1 

^9 

Sll 

KF-ZR,  TL(1)-6,TL(2)-KF,  ZFC-ZR 

• 

^1 

^9 

SlO  Sll 

"2  = 

KF-ZR,  TL(l)-6,  TL(2)«KF,  ZRF-ZRF+1 

ZQ(Z3)-ZF,  ZV(Z3)-ZN 

ZB(Z3)-ZI,  ZDQ(z3)-3 

Z3*Z3+ZQ(z3)+1,  ZD-1,  ZFC-ZR 

^1 

S7  Ss  Sll 

'3’ 

KF-ZR-2,  TL(l)-5,  TL(2)-KF,  ZFC-ZR 

^1 

^6 

Sa  Sll 

"4  = 

KF-ZR+2.  TL(l)-5,  TL(2)-KF,  ZFC-ZR 

^1 

^5 

Sll 

ZFC-ZR 

^1 

^4 

S7  S3  Si, 

KF-ZR-1,  TL(l)-5,  TL(2)=KF,  ZFC-ZR 

S4 

Ss  Sll 

"7-' 

KF-3,  TL(l)-5,  TL(2)-KF,  ZFC-ZR 

^1 

S3 

S7  Sg 

KF-ZR-3,  TL(l)-5,  TL(2)-KF,  ZFC-ZR 

^I 

S3 

Sa  Sll 

"9  = 

KF-ZR+1,  TL(l)-5,  TL(2)-KF,  ZFC-ZR 

is  not  listed  in  the  segment  sequences  because  it  does  not  affect  the 
computation  of  the  output  values.  (Its  value  is  involved  only  in  branch 
expressions.)  In  the  equations  for  the  value  of  KF  in  F^,  F^,  Fg,F^,  Fg, 
and  Fg  the  algebra  involved  in  the  several  executable  statements  involving 
KF  has  been  performed.  The  description  of  the  F^  given  above  defines  the 
values  of  all  output  variables  in  terms  of  functions  of  values  of  input 
variables . 
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3.3  A Functional  Version  of  Routine  B 

The  Infonnacion  developed  in  the  FP  analysis  of  Routine  B - viz,,  the 
Gj , Lj , and  Fj  - can  be  used  to  rewrite  the  routine  as  a functional  progran. 
Examination  of  this  information  shows  that  S^:  IT.EQ.O  is  not  needed  to  parti- 
tion  the  input  domain.  If  Sg  is  eliminated,  the  executable  statements  involv- 
ing IT  can  also  be  eliminated,  for  they  also  do  not  contribute  to  the  computa- 
tion of  the  Fj . IT  appears  in  two  segments,  $2  and  S^.  It  can  be  removed 
from  $2  by  defining  a new  segment  $2; 

e S*:  S2-U1*'*2/(U1**2  + U2**2) 

Since  is  the  statement  IT  ■ 0,  it  can  be  eliminated  completely. 


To  determine  the  branching  sequence  for  the  FP  version,  it  is 
convenient  to  list  the  branch  expressions  for  the  input  domain  partitions  Gj 


• 

"r 

U3.lt. ZE(K) , 

ZD.EQ.l 

^2= 

U3.LT.ZE(K), 

ZD.NE.l 

U3.GE.ZE(K), 

S2.LT.ZA, 

U2.LT.0, 

KF.GT.3 

^4  = 

U3.GE.ZE(K), 

SZ.LT.ZA, 

U2.LT.0, 

KF.LE.3 

U3.GE.ZE(K) , 

S2.LT.ZA, 

U2.GE.0 

^6  = 

U3.GE.ZE(K), 

S2.GE.ZA, 

Ul.LT.O, 

KF.GT.3 

U3.GE.ZE(K) , 

S2.GE.ZA, 

Ul.LT.O, 

KF.LE.3 

00 

0 

U3.GE.ZE(K) , 

S2.GE.ZA, 

Ul.GE.O, 

KF.GT.3 

U3.GE.ZE(K) , 

S2.GE.ZA, 

Ul.GE.O, 

KF.LE.3 

To  structure  Routine  B as  a functional  program,  list  the  execution 
sequences  for  the  9 logic  paths,  removing  and  Sg  and  substituting 


S.  for  So : 

L ^ 


^1  ^11 


T • 


Si  S^  Sq  S^  S^q  S^j_ 


L3:  Sj_  S^  S2  S2  Sg  Sg  S^  Sg  S^2 


• L 


k' 

5* 


^2  ^2  ^4  ^6  ^5  ^8  ^11 


c c c 5*  s 

-1  ^2  ^2  ^4  ^11 
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L^:  sj  S*  sf  S 


3 ‘'4  “5  “'7  “8  “'ll 


• h’  h =2  =2  =3  ^4  4 h hi 

• ‘•3=  =1  4 h *3  =3  =5  =7  =8  5il 

• S’  S 4 h 4 4 h ^S  S hi 


Sj  is  also  removed  from  L^  since  it  is  not  necessary. 

Examination  of  the  shows  there  are  no  functional  redundancies; 
however,  it  shows  that  F^,  F^,  Fg,  F^,  and  Fg  differ  only  in  their  handling 
of  KF.  KF  is  defined  initially  in  as  KF  ■ ZR,  for  all  Fj . The  KF 
computation  sequences  for  these  are: 


• 

^3  = 

Sg  S^: 

KF  - 

KF+2, 

KF 

- KF-4 

^4  = 

^6  ■ 

KF  =• 

KF+2 

S4S7  : 

KF  = 

KF+3, 

KF 

- KF-4 

F • 

^7- 

S4  ' 

KF- 

KF+3 

^8* 

S3S7  : 

KF  - 

KF+1, 

KF 

» KF-4 

F • 
9* 

S3  : 

KF  - 

KF+1. 

Since  Che  KF  computation  sequences  involve  incrementing  KF  by  1,  2,  or  3 
and  since  the  variable  K is  defined  in  as  KF  + 1,  the  computation 

sequences  can  be  simplified  by  redefining  K to  be  ZR  + 1 and  replacing 
KF  by  K.  The  incrementing  sequences  then  become: 

• Fg:  K=-  K+1,  K - K-4 

• F^ : K - K+1 

• Fg:  K-  K+2,  K * K-4 

• F_:  K»  K+2 

• F„ : K - K-4 


This  can  be  done  by  eliminating  segment  S,,  since  it  does  not  change  the 
value  of  K and  redefining  segments  S^,  S^,  Sg,  S^,  and  S-. 
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• S*:  K - ZH+l 

U1  - -ZT(2) 

U2  - -ZT(3)*ZS(K)+ZT(7)*ZC(K) 

U3  - ZT(3)*ZC(K)+ZT(7)*ZS(K) 

• S*:  K - K+2 

• S*:  K - K+1 

• S*:  K - K-4 

• Sj*:  K.GT.3 

Since  Sg  and  Sg  involve  KF,  they  must  be  changed: 

• S*:  TL(1)  - 5 

TL(2)  - K 

• S*:  TL(1)  - 6 

TL(2)  - K -1 


Also  note  chat  the  FALSE  evaluation  of  S^  branches  directly  to  Sj^^^  while 
Che  TRUE  evaluation  is  followed  by  S^  S^  involving  further  branching. 
Thus  the  code  can  be  simplified  by  replacing  S^  by  its  complement: 

• S^*:  U2.GE.0 


With  these  substitutions,  Che  execution  sequences  become: 
• L, 


* c * c 
Si  S,  Sg  s,  s^. 


'2*  ^1  ^1  ^9  ^7  ^10  ^11 

*f*tf**t**  * 

'3*  ^1  ^1  ^2  ^2  ^4  ^6  ^5  ^7  ^3  ^11 

* f * c f*  * f*  * 

S,  S^  S^  S,  S,  S,  Sg  Sg  S,, 

* f * c c* 

S S S S S S 

...  0^  ^2  =>2  ^4  ^11 

Af*ft*t**  * 

.g:  S,  S^  S2  S2  Sg  S,  Sg  S,  Sg  S,, 


f * f - 

s,  s^  s,  s:  s:  s,  s 


f * * 

5 Sg 


♦f*fft*** 

s s s s s s s s s 

^2  ^2  ^3  ^5  ^7  ^3  ^11 

★ f * f • * 

$1  Sj_  Sg  Sg  S*  Sg  Sg  Sj_j_ 
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A program  having  these  logic  paths  can  be  written  in  FP  notation: 

* 


IF  GOTO  Sg 


If  k* 

IF  GOTO  S- 
2 4 

k * 

IF  S3, 


GOTO  S 


k* 


IF  S^*  GOTO  S.. 
4 11 


k* 

IF  S5  , S- 

A 

^8 

GOTO 

A 


IF  GOTO 


10 


"11 

The  logic  diagram  shown  in  Figure  3—4  for  this  form  of  Routine  B shows 
that  it  has  9 paths. 
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Figure  3-4.  Structure  of  Revised  Routine  B 


This  version  is  not  a structured  program,  for  the  branch  of 
creates  a cross-link,  forbidden  by  structured  programming  rules.  It  can 
be  converted  into  a structured  FORTRAN  program  (modelling  structured  programm- 
ing control  structures  in  terms  of  FORTRAN  IF  and  GOTO  statements) , while 

remaining  a functional  program,  by  introducing  some  logical  complications. 

k k* 

One  way  is  to  combine  S„  and  S,  into  a compound  branch  expression 
k k*  I h 

S2.AND.S^  . This  involves  replacing  the  structure: 
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by: 


k k* 

IF  $2  goto 

IF 

(S2.AND 

.S^*)  GOTO  S 

_k  _* 

k 

it 

IF  Sj, 

IF 

$2  goto 

^6 

k* 

GOTO  Sj 

IF 

-k  -* 

S3  , 

IF  GOTO  S, , 

4 11 

k* 

GOTO 

11 


which,  while  having  the  same  number  of  lines  of  code,  has  the  complication 

of  a compound  Boolean  expression.  Another  way  of  writing  a functional 

PORTRAIT  program  conforming  to  structured  programming  rules  (modelling 

structured  programming  control  structures  in  terms  of  FORTRAN  IF  and  GOTO 

* * 

statements)  combines  segments  S,  and  S^,  combines  and  S^,  and  replaces 

If  ^ k 

by  three  branch  expressions:  one  in  the  FALSE  branch  of  S«,  one  in  the 

TRUE  branch  of  and  one  in  tne  FALSE  branch  of  S,  . This  version  Increases 
3’  4 

the  number  of  executable  statements  but  involves  no  compound  expressions. 

Substituting  the  definitions  of  the  segments  and  branch  expressions 
into  the  first  FP  version  produces  the  following  code  for  Routine  B: 


K - ZR+1 
U1  --ZT(2) 

U2  — ZT(3)*ZS(K)  + ZT(7)*ZC(K) 
U3  - 2T(3)*ZC(K)  + ZT(7)*ZS(K) 
IF  (U3.LT.2S(K))  GOTO  100 
S2  - U1**2/(U1**2  + U2**2) 

IF  (S2.LT.ZA)  GOTO  10 
IF  (Ul.LT.O)  K - K + 2 
GOTO  50 

10  IF  (U2.GZ.0)  GOTO  200 
K - K+1 

50  IF  (K.GT.3)  K = K-4 
TL(1)  = 5 
TL(2)  - K 
GOTO  200 
100  TLCl)  - 6 

TL(2)  - K-1 
IF  (ZD.EQ.l)  GOTO  200 
Z2F  - ZRF-^l 
ZQ  (Z3)  - ZF 
ZV  (Z3)  - ZN 
Z3  (Z3)  - ZI 
ZDQ  (Z3)  - 3 
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Z3  - Z3  + ZQ(Z3)  + 1 
ZD  - 1 

200  ZFC  - ZR 

retur:i 

era 

This  version  of  Routine  B has  27  executable  statenents  compared  to  35  in 
the  original  version. 

3.4  Performance  Iraprovement 

A 

•t 

Because  the  FP  version  of  Routine  B reduced  the  number  of  executable 

statements  and  did  not  introduce  any  complication,  it  undoubtedly  Improves 

the  performance  - i.e.,  reduces  primary  storage  requirement  and  execution 

time.  A further  small  performance  improvement,  a reduction  in  execution 

time,  is  possible  by  investigating  whether  the  execution  sequences  in  any 

of  the  logic  paths  contain  any  unnecessary  executions  - i.e.,  executable 

statements  that  do  not  contribute  to  branching  or  computing  of  output 

values.  It  is  readily  apparent  that  two  statements  in  - viz.,  the 

statements  assigning  values  to  U1  and  U2  - are  not  needed  in  paths  and 

L-  although  they  are  needed  for  the  remaining  7 paths.  These  unnecessary 
^ * * 
executions  in  and  L2  can  be  removed  by  redefining  and  82: 

** 

; K - ZR  + 1 

U3  - ZT(3)*ZC(K)+ZT(7)*ZS(K) 

S**:  U1  - -ZT(2) 

U2  - -ZT(3)*ZS(K)+ZT(7)*ZC(K) 

S2  - U1**2/(U1**2+U2**2) 

This  change  does  not  change  the  number  of  executable  statements  but  it 
should  reduce  execution  time  for  and  L2. 

Test  runs  were  made  on  Routine  A.  It  was  found  that  the  FF  version, 
in  spite  of  its  having  a compound  Boolean  expression,  compiled  on  the 
CDC  7600  computer  into  approximately  2/3  the  amount  of  primary  storage  as 
the  original  version  and  it  executed  in  2/3  the  time.  This  performance 
improvement  is,  of  course,  dependent  on  the  compiler. 
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3.5  Effect  of  Sahroutlr.es 


Although  Routine  A and  Routine  B do  not  contain  subroutines,  many 
programs  do.  FP  analysis  of  programs  containing  subroutines  proceeds  sim- 
ilarly to  FP  analysis  of  programs  having  no  subroutines,  in  terms  of  input 
domain  partitions,  functions  and  logic  paths;  however,  the  analysis  of  the 
input  domain  partitions  must  determine,  for  each  input  variable,  whether 
the  value  is  obtained  from  sources  external  to  the  program  or  as  a result 
of  execution  of  one  of  the  subroutines.  For  those  input  values  obtained 
from  execution  of  a subroutine,  the  range  of  output  values  produced  by  the 
subroutine  must  be  compared  with  the  allowable  input  values.  The  descrip- 
tion of  the  function  associated  with  each  input  domain  partition  must  in- 
clude the  effects  of  execution  of  the  subroutines  included  in  its  associated 
logic  path. 

To  illustrate  FP  analysis  of  such  programs,  a program  called 
"Routine  C",  containing  calls  to  subroutines  is  used: 

Routine  C 


^1 

CALL  TPR 

k 

^1 

IF  (ZR)  500, 

500, 

100 

^2 

100 

CALL  TZD 

^2 

150 

IF  (Z3)  200, 

200, 

550 

200 

ZG  - ZG  -r  1 

ZC  - 0 

CALL  TCO 

^4 

300 

CALL  TRA 

GOTO  2000 

^5 

500 

cojrriNUE 

Z3  - 1 

GOTO  150 

^6 

550 

C0NTI>:UE 

CALL  TEC 

ZB  - Z3  + 1 
ZC  - ZC  + 1 
GOTO  300 


2000  RETUSN 


END 

Routine  C has  7 segments  and  two  branch  expressions.  In  the  assignment  of 
F?  symbols  to  elements  of  Routine  C,  the  subroutine  calls  are  treated  as 
executable  statements. 

Following  the  steps  in  the  FP  analysis  procedure,  the  second  step  in 
the  analysis  is  to  write  Routine  C in  FF  notation: 


IF  (sp  Sj.  S^,  $2 
k 

IF  (Sp  Sj,  Sj,  Sg 


"4 

GOTO 

S. 

GOTO  s' 
^6 

GOTO  S, 


The  logic  diagram  is  then: 


t" 
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Despite  the  somewhat  confusing  placement  of  S^,  S^,  and  in  the  program  code, 
the  logic  diagram  shows  that  Routine  C has  the  structure  of  a structured 
program. 


The  input  variables  for  Routine  C are: 
• ZR,  Z3,  ZG,  ZB,  and  ZC. 


Branch,  expression  partitions  the  set  of  possible  values  of  ZR 
into  those  specified  by  ZRiO  and  those  specified  by  ZR  > 0.  Evaluation  of 
to  be  less  than  0 or  to  be  equal  to  0 transfers  execution  to  S5  followed 

by  evaluation  of  S.,  which  partitions  the  set  of  possible  values  of  Z3.  Since 

^ + • 0 
sets  Z3*l,  the  only  executable  sequence  is  S^.  and  $2  are 

phantom  sequences.  Evaluation  of  to  be  greater  than  0 transfers  execution 

to  S2,  followed  by  evaluation  of  S2*  Since  the  value  of  Z3  is  not  assigned 

in  any  executions  in  this  sequence,  all  S^  evaluation  possibilities  are 

possible  . The  logic  paths  of  Routine  C are  then: 


L,: 


• h = 


$1  Sj^  S5  $2  Sg  S^  S^ 
Si  S*  Sj  sf  S3  Sj 


=1  < =2  4 h h 


S, 

/ 


Routine  C has  one  phantom  path,  the  path  containing  the  sequence  Sj  S2  . 
The  notation  S2^  is  used  to  denote  that  the  < 0 and  0 evaluations  of  the 
arithmetic  IF  statement  transfer  to  the  same  segment  and  therefore  do  not 
produce  distinct  sequences. 


The  input  domain  partitions  for  these  paths  are: 


• 

^r- 

ZR 

< 

0, 

ZB,  ZC. 

• 

ZR 

> 

0, 

Z3  _<  0, 

ZG. 

• 

ZR 

> 

0, 

Z3  > 0, 

Z3,  ZC. 

The  segment  sequences  for  each  logic  path  specify  the  functions  : 


Si  S5 


^1  ^2  ^3  ^4  ^7 


• ^2  Sg  S. 


F^;  TPR,  Z3-1,  TEC,  ZB-Z3  + 1, 

ZC-  ZC  + 1,  TRA. 

F2:  TPR,  TED,  ZG-ZG  -f-  1,  ZC  - 0,  TCO,  TRA. 

F3;  TPR,  TED,  TEC,  Z3-23  + 1,  ZC=ZC  -^1, 
TRA. 
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In  the  description  of  the  functions,  F^,  the  effect  of  each  subroutine 
is  represented  by  its  name.  From  these  function  descriptions,  it  is 
apparent  that  Routine  C acta  principally  to  call  subroutines  TPR,  TED, 

TEC,  TCO,  and  TRA.  It  always  calls  TPR  and  TRA.  Calling  of  TED,  TEC, 
and  TCO  depends  on  the  to  which  the  input  E^  belongs. 

For  the  most  part,  these  subroutines  when  called  obtain  their  input 
from  a common  data  base,  used  by  many  routines  in  the  large  software 
system  from  which  these  routines  were  chosen.  They  record  their  output  in 
that  data  base.  Routine  TED,  alone  of  these  routines,  changes  a value  of 
a variable,  Z3,  used  in  the  explicit  calculations  of  Routine  C.  TED  out- 
puts Z3  ■ 0 or  Z3  1 . 

Thus  for  and  G^,  the  values  for  input  variable  Z3  are  obtained  as  a 
consequence  of  the  execution  of  TED.  These  values  are  within  the  range 
specifications  for  Z3;  therefore,  execution  of  TED  is  completely  compatible 
with  the  execution  of  Routine  C.  Input  values  for  ZR,  ZB,  ZC,  and  ZG  are 
obtained  from  the  common  data  base,  where  they  have  been  placed  as  the  result 
of  execution  of  routines  outside  of  Routine  C. 

In  general,  analysis  of  subroutine  interfaces  is  more  complicated 
chan  in  this  example.  It  will  generally  involve: 

• determination,  for  each  subroutine,  of  Che  inputs,  if  any, 
it  receives  from  execution  of  the  calling  routine. 

s comparison  of  the  allowable  values  for  these  inputs  with  the 
values  computed  by  the  calling  routine. 

• determination,  for  each  subroutine,  of  output  values,  if  any, 
computed  by  it  and  used  in  execution  of  the  calling  routine. 

• comparison  of  these  output  values  t/ith  the  allowable  ranges 
of  the  variables  to  which  they  are  assigned  in  the  calling 
program. 

If  any  incompatibilities  of  ranges  are  found,  they  may  indicate  a problem 
and  the  effect  of  the  incompatibilities  must  be  analyzed  further. 
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Fron  the  FP  notation  representations  of  the  for  Routine  C,  it  is 
relatively  easy  to  rewrite  the  routine  as  a functional  prograa.  In  FP 
notation,  it  is: 


and  in  FORTRAN  notation: 


1 k 
IF  (Sp 


IF  (S2) 


*'3 

GOTO  S, 


CALL  TPR 

IF  (ZR)  500,  500,  100 
100  CALL  TED 

IF  (Z3)  200,  200,  550 
200  ZG  = ZG  + 1 

ZC  - 0 

CALL  TCO 
GOTO  600 
500  Z3  =•  1 

550  CALL  TEC 

Z3  - ZB  + 1 

ZC  - ZC  + 1 

600  CALL  TRA 

RETURN 
END 
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It  contains  14  executable  statements  compared  to  16  In  the  original  version. 
Although  the  new  version  has  fewer  executable  statements  and  no  phantom 
paths,  it  is  not  a structured  program.  The  branch  creates  the  path 

L-  by  cross-linking  and  L-.  To  convert  it  to  a program  having  the 

^ k 

structure  of  a structured  progr.m  requires  either  routing  through  S2, 

as  is  done  in  the  original  program,  creating  a phantom  path,  or  duplicating 

the  code  for  S^,  as  in  the  following; 


IF  (Sp  S5,  S5,  S2 

^2  ^ 
IF  (S2)  S3,  S3,  S* 

^3 

GOTO  S, 


"6 

GOTO  S, 


denotes  a block  of  code  identical  to  the  code  in  S^.  It  is  apparent  that 
either  method  produces  a program  structurally  more  complicated  than  the 
unstructured  functional  program. 
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3 . 6 Effect  of  Assembly  Language  and  Interrupts 


Although  the  initial  exploration  of  F?  concepts  was  perforaed  by 
analyzing  higher  order  language  programs,  the  concepts  are  also 
applicable  to  assembly  language  programs.  For  such  programs,  the  inputs 
include  storage  addresses,  contents  of  machine  registers,  and  interrupts. 
To  show  how  FP  analysis  can  be  used  to  analyze  assembly  language  software, 
a collection  of  routines  from  a communications  software  package  on  the 
H 316  computer  were  analyzed.  These  routines  are  concerned  with  interrupt 
processing. 

The  text  of  these  routines,  annotated  by  writing  segment  labels  in 
the  left  hand  margin  is: 


Segment 

^1 

So 


S 


6 


S 


7 


Storage  Location 

Routine 

Instruction 

12634 

HI0E: 

INT  H2I 

12635 

JST  HISB2 

12636 

HUE: 

INT  H2I 

12637 

JST  HISB2 

12640 

HI2E: 

INT  H2I 

12641 

JST  HISB2 

12642 

HI3E: 

INT  H2I 

12643 

JST  HISB2 

12644 

HISB2: 

0 

12645 

STA  (HIA)I 

12646 

STX(HIX)I 

12647 

LDA  HISB2 

12650 

SUB  (HUE) 

12651 

STA  0 

'l2652 

LDA  HI0EX 

12653 

STA  HISB 

12654 

LDA  0 

12655 

ARS  1 

12656 

STA  0 

12657 

JKP  HISB 11 

12660 

HISS: 

0 

12661 

STX  (HIX)I 

12662 

STA  (HIA)I 

12663 

HISBl: 

D.XA 

12664 

JMP  (HISBIDI 

Sg  13046 

13047 

13050 

13051 

13052 

13053 

13054 

13055 

13056 


HISBll;  STX  HIP 
INK 

STA  HIK 
LDA  HIM 
SMK  INTM 
IMA  PRIM 
STA  HIMS 
ENB  H2I 
JMP  HILO 


Each  of  these  routines  consists  of  a single  segment.  The  structure  of  this 
collection  of  routines  is  shown  in  the  diagram  in  Figure  3->5. 


Note  that  there  are  no  branch  expressions  in  these  routines.  The  routine 
collection  can  be  entered  from  Sj,  S^,  or  Sg,  which  connect  to 

either  S,  or  S_. 

5 / 

S2.  S^,  and  S^  are  entered  respectively  when  one  of  four  possible 
interrupts  occurs.  The  H316  computer  responds  to  an  interrupt  signal  by 
interrupting  the  processing,  setting  the  computer  in  the  extended  address 
mode,  and  making  a jump  to  the  routine  for  processing  the  interrupt,  HI0E, 
if  interrupt  signal  0 occurs,  HUE,  if  interrupt  signal  1 occurs,  HI2E, 
if  interrupt  signal  2 occurs,  and  HI3E,  if  interrupt  signal  3 occurs. 

The  addresses  of  these  routines  are  given  in  storage  locations  to  which 
the  respective  Interrupts  trap  and  are  loaded  into  those  locations  in  an 
initialization  process.  The  H316  interrupt  operates  by  storing  the 
address  L of  the  next  instruction  that  would  have  been  processed,  had  the 
interrupt  not  occurred,  in  the  first  storage  location  of  the  interrupt 
processing  routine. 
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Each  of  the  initial  interrupt  processing  routines,  and  therefore,  r .e 
segments  S^,  S2>  S^,  and  S^,  consists  of  a single  instruction  JST  KISBC , 
which  causes  execution  to  transfer  to  subroutine  HIS32  at  storage  location 
12644.  JST  stores  in  that  location  the  address  of  the  next  sequential 
location  following  the  JST  - viz.,  12636  for  HI0E,  1264C  for  HUE,  12642 
for  HI2E,  and  12644  for  HI3E.  These  addresses  are  used  in  KISB2  indicating 
which  interrupt  signal  occurred. 

Thus  the  inputs  to  the  routines,  HI0E,  HUE,  HI2E,  and  HI3E,  are  the 
hardware  signal  I,  initiating  the  interrupt  that  selects  the  routine,  and 
the  address  L of  the  instruction  that  would  have  been  processed  had  the 
interrupt  not  occurred.  The  outputs  of  these  routines  are  the  address  L 
and  the  address  B,  denoting  the  specific  interrupts.  The  functions  performed 
by  the  routines  are  to: 

• save  the  address  L,  and 

a convert  the  hardware  signal  into  B 

The  hardware  signal  I can  only  have  four  possible  values  and  to  each  of 
these  values  there  corresponds  a unique  value  of  B. 

The  inputs  to  the  routine  HISB2  are  B and  the  contents  A of  the  A- 
register  and  X of  the  Index  register.  Since  B can  have  only  4 possible 
values  - 12636,  12640,  12642,  or  12644  - its  range  is  limited  to  these 
values.  From  the  internal  structure  of  HIS32,  the  range  could  be  any 
possible  value  that  could  be  stored  in  the  16  bit  word;  however,  the 
possible  values  of  B are  limited  by  the  4 routines  which  transfer  to  HISB2. 
The  outputs  of  H1SB2  are  A,  S,  the  interrupt  number  H,  and  the  address  L. 

The  functions  of  HIS32  are: 

• save  the  values  of  A and  X by  storing  them  in  HIA  and  HIX, 

• compute  the  interrupt  number  H from  B and  store  it  in  the 
index  register, 

m compute  address  of  L and  store  in  HIS3. 

KI332  will  compute  the  correct  interrupt  number  (0,1,2,  or  3)  if  presented 
with  the  correct  values  of  3;  however,  if  presented  with  any  other  value 
of  B,  it  will  compute  and  score  in  the  index  register  a value  which  is  not 
Che  number  of  any  interrupt.  HISB2  therefore  has  capabilities  which  are  not 
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needed  for  the  Interrupt  processing  and  which  if  used  could  lead  to 
Improper  functioning.  It  does  appear  that  any  such  trouble  is  unlikely, 
for  the  software  inputs  to  HISB2  should  only  produce  proper  input  values 
and  only  hardware  errors  can  lead  to  Improper  Inputs.  Nevertheless,  the 
routines  HI0E,  HUE,  HI2E,  HI3E,  and  HISB2  are  examples  of  "clever"  programm- 
ing, which  is  hard  to  interpret,  and  which  produces  hidden  capabilities  that 
frequently  are  sources  of  problems. 

Routine  HISB  provides  a software  entrance  to  this  routine  collection. 
Its  inputs  are  return  addresses  stored  in  the  first  location  of  HISB  for 
later  use  by  the  routine  HIDONE,  X,  and  A.  Its  outputs  are  the  return 
addresses,  X,  and  A.  Its  functions  are: 

• save  the  return  address  in  HISB. 

• save  che  contents  of  the  A-register,  in  HIA, 
and  the  contents  of  Che  X register,  in  HIX. 

The  input  to  Che  routine  HISBl  is  Che  address  state  of  Che  computer 
(extended  address) . The  output  is  a signal  Co  change  Che  address  state  Co 
normal  address.  The  function  of  Che  routine  is  Co  change  the  address  state 
of  Che  computer  from  extended  address  mode  to  normal  address  mode. 

The  inputs  to  routine  HISBll  are  the  current  interrupt  number  (stored 
in  the  index  register),  keys  (obtained  from  hardware  registers,  the  new 
interrupt  mask  (stored  in  HIM),  the  old  priority  mask  (stored  in  PIM)). 

The  outputs  are: 

• current  interrupt  number,  stored  in  HIP. 

• the  keys  stored  in  HIK. 

• new  interrupt  mask  stored  in  PRIM  and  output  to  register  INTM. 

• Che  old  priority  mask  stored  in  HIMS. 

• a bit  enabling  interrupts  after  exit  from  the  routine. 

The  functions  of  the  routine  are: 

« save  current  interrupt  number. 

• acquire  and  score  keys . 

• sec  up  new  interrupt  mask. 

• save  old  interrupt  mask. 

• enable  interrupts. 
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No  computations  are  performed,  only  the  places  where  various  values  a-e 
stored  are  changed. 

There  are  5 logic  paths  through  this  collection  of  routines: 


‘'I 

^2 

L, 


Si.Ss.Sg 
Sz.Ss.Sg 
Sa.Sg.Sg 
S^.Sg.Sg 

The  inputs  to  the  routines  are: 

I,  the  interrupt  signal  which  selects  the  entrance  routine. 

L,  the  return  address. 

A,  the  contents  of  the  A register. 

X,  the  contents  of  the  index  register. 

K,  the  keys,  from  hardware  registers. 

NM,  the  new  priority  mask,  obtained  from  HIM. 

OM,  the  old  priority  mask,  obtained  from  PRIM. 

The  subsets  Gj  are: 

A,X,K,NM,  and  OM,  which  are  common  to  all  G^’s. 

The  set  of  addresses,  L,  of  the  portions  of  the  IMP  software 
which  are  interruptable  are  common  to  G^,G^,Gg,  and  G^ . 

The  value  of  I which  selects  routine  HIDE. 

The  value  of  I which  selects  routine  HUE. 

The  value  of  I which  selects  routine  HI2E. 

The  value  of  I which  selects  routine  HI3E. 

The  outputs  of  the  routines  are: 

N,  the  current  interrupt  number,  stored  in  HIP. 

L,  the  return  address  for  use  when  the  interrupt  processing 
is  completed,  stored  in  HISB. 

• A,  the  contents  of  the  A register  before  the  interrupt,  stored 
in  HIA. 
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• X,  the  contents  of  the  index  register  before  the  interrupt, 
stored  in  HIX. 

• K,  the  keys,  set  into  a hardware  register  and  stored  in  HIK. 

• OM,  stored  in  HIMS. 

• NM,  stored  in  PRIM. 

• mode  change  to  extended  addressing  and  enable  interrupts. 

The  functions  of  the  routine  collection  are: 

• Compute  current  interrupt  number. 

• Save  the  contents  of  A and  X registers. 

• Save  the  return  address. 

• Set  keys  in  hardware. 

m Save  old  priority  mask. 

• Store  new  priority  mask  in  PRDI. 

• Enable  interrupts  after  completion  of  the  processing. 

• Change  address  mode  from  extended  address  to  normal  address  after 
current  interrupt  number  computation  is  complete. 

Although  this  collection  of  routines  is  structurally  and  functionally 
simple,  the  analysis  of  the  routine  collection  by  FPA  demonstrates  the 
applicability  of  the  technique  to  assembly  language  software,  shows  that 
application  of  the  technique  is  relatively  straightforward,  and  shows  the 
level  of  detail  to  which  the  analysis  can  be  carried  in  obtaining  a clear 
understanding  of  both  intended  and  unintended  functional  capabilities  of 
software. 
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4,0  COMPOSITION  OF  FUNCTIONAL  PROGRAMS 

FP  theory  can  be  used  to  guide  the  writing  of  programs.  The 
basic  FP  association  of  input  data  partitions,  logic  paths,  and  functional 
requirements  is  used  but  is  applied  in  the  inverse  order.  That  is,  function- 
al requirements  are  defined  first,  then  the  input  domain  partitions,  next 
the  logic  paths,  and  finally  the  program.  This  approach  assures  traceability 
of  the  functional  requirements  to  the  code  structures.  It  also  assures  that 
the  requirements  on  the  program  are  defined  first  rather  than  plunging  into 
writing  code  based  on  a vague  concept  of  what  the  program  is  intended  to  do. 
The  FP  method  tells  how  to  write  the  requirements  and  how  to  translate  them 
into  a formal  specification  of  the  program.  The  result  is  more  explicit, 
complete,  and  precise  requirements,  ensuring  that  the  program  written  is  the 
one  desired. 

The  FP  method  is  described  in  section  4.1.  In  following  sections,  it 

■ < 

is  explained  by  showing  how  to  use  it  in  writing  programs.  Section  4.8 
further  discusses  the  writing  of  functional  programs  containing  loops. 


4.1  Method  for  Writing  Functional  Programs 

The  method  for  writing  functional  programs  is  a step-by-step  applica- 
tion of  the  FP  basic  association,  beginning  with  the  functional  requirements. 
The  steps  are: 

1.  write  an  informal  requirements  specification  - i.e.,  a set  of  state- 
ments defining  the  functions  the  program  is  required  to  perform. 

2.  Translate  these  functional  requirements  into  a formal  specification 
defining  the  and  F^  in  mathematical  and/or  logical  terms. 

3.  Identify  any  functional  redundancies  - i.e.,  two  or  more  ' s 
associated  with  the  same  F^ . 

4.  Remove  the  functional  redundancies  by  forming  the  union  of  the 
G.'s  associated  with  the  same 

1 j 

5.  write,  in  the  programming  language  to  be  used  for  the  program,  the 

branch  expressions  defining  the  partition  constraints  for  each  G . 

k J 

Assign  FP  symbols  S to  the  branch  expressions. 
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6. 


Write  the  code  segment  sequences  specifying  the  . 

Assign  FP  symbols  to  the  segments. 

7.  Design  program  by: 

a)  determining  sequencing  for  execution  of  branch  expressions, 

b)  defining  program  logical  structure  in  FF  notation. 

8.  Write  program  in  programming  language  by  substituting  code 
definitions  for  the  and  Sj. 

4.2  Informal  Requirements  Specif Icatlon 

The  FP  method  will  be  explained  by  applying  it  to  designing  and 
v^riting  a program  tc  create  and  maintain  a stack  data  structure.  The 
first  step  is  to  decide  what  the  program,  named  "STACK",  is  to  do.  This 
is  done  by  writing  an  informal  requirements  specification,  defining  the 
functions  STACK  is  required  to  perform. 

Since  the  purpose  of  STACK  is  to  create  and  maintain  a stack  data 
structure,  that  data  structure  must  be  defined.  A stack  data  structure  is 
an  ordered  finite  list  of  data  elements  accessible  from  its  top;  l.e., 
elements  of  the  stack  can  be  added  to  the  top  or  removed  from  its  top. 

For  the  purpose  of  this  example,  the  data  elements  will  be  chosen  to  be 
integers  in  the  range  the  variable  I denoting  an  arbitrary  integer 

and  IM  denoting  the  maximum  integer  value  allowed  in  the  stack. 

The  informal  requirements  specification  of  STACK  is: 

• STACK  is  required  to  perform  the  following  functions,  as  selected 
by  the  user: 

• Accept  an  integer  input  value  I and 

• test  the  value  of  I for  being  within  the  acceptable 

range,  and 

• create  stack  data  structure  JS,  or 

• push  value  of  I onto  top  of  stack,  unless  stack  is 
maximum  size,  J « JM. 
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• User  options  not  involving  integer  input: 

• Fop  stack,  removing  top  value,  unless  stack  is 
empty,  J « 0. 

• Determine  value  of  top  element  of  STACK,  JS(J), 
unless  stack  is  empty,  J - 0. 

• Determine  number  of  elements  in  stack,  the  value  of  J. 

• Save  after  each  execution, 

• the  stack  JS,  and 

• the  number  J of  elements  in  the  stack. 


4.3  Formal  Specification 


The  next  step  is  to  translate  the  informal  statement  of  the  require- 
ments into  a formal  specification  defining  the  and  precisely  and 
completely.  First  the  stack  data  structure  JS  is  defined  as  an  ordered 
J-tuple,  (I^,  I2,  ...,  Ij) . Each  in  the  J-tuple  is  an  integer  in  the 
range  and  J,  the  number  of  elements  in  the  tuple  (stack),  is  an 

integer  in  the  range  the  value  J = 0 denoting  an  empty  stack;  i.e: 


JS 


( 1^ » I2  > * ' 


0, 


Ij^J^J,  unless  J 

0£j£jM, 

J “ 0 denotes  an  empty  stack. 


JS(J) 


Ij,  top  element  in  stack. 


To  completely  define  the  inputs,  a design  decision  on  how  to  represent 
the  user  option  choices  must  be  made.  For  simplicity,  the  user  option  choice 
will  be  represented  by  an  integer  value  assigned  to  an  input  variable  K. 


The  Gj”  and  F^  may  now  be  defined: 
G^:  K-1,  0_<I_<IM  3 


G„:  K=l,  r<0  or  E>  IM 


J-1,  JS(1)  - I, 

Print:  STACK  CREATED 


Print 


RA^GE  ERROR 
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r 


K-2,  O^I^m,  JS, 
0_<J<JM 

F • 

F3. 

J’  - J+1,  JS(J')  - I, 

Print;  VALUE  ADDED 

^4^ 

K-2,  J-JM 

F • 

''4' 

Print; 

STACK 

FULL 

S' 

K-2»  I<0  or  I>IM 

S' 

Print ; 

RANGE 

ERROR 

S' 

K-3,  0<J_<JI  I 

S' 

J'  - J 

Print; 

- 1. 

VALUE 

REMOVED 

S' 

K-3,  J-0 

S’ 

Print; 

STACK 

EMPTY 

S' 

K-4,  0<J_<JM,  JS 

F • 
8* 

Print; 

Value 

of  JS(J) 

S' 

K-4,  J-0 

F • 

S' 

Print: 

STACK 

EMPTY 

'10 ' 

K-5,  0^J<^I 

So* 

Print : 

Value 

of  J 

’ll' 

K<1  or  K>  5 

F 

Si* 

Print ; 

OPTION  ERROR 

This  set  of  Gj  and  definitions  nay  be  graphically  represented 
(Figure  4-1)  to  clarify  the  relationships  of  the  input  branch  variables. 
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Figure  4-1.  Graphical  Representation  of  STAGC  Functions 
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Noce  that  the  function  is  not  defined  in  the  informal  specification. 

Its  inclusion  in  the  formal  specification  came  from  noting  that  the  user 
option  input  variable  was  defined  for  the  values  1,  2,  3,  4,  and  5 but  was 
undefined  for  other  values.  Unless  a response  is  defined  for  these  other 
values  of  K,  the  program  could  be  made  to  execute  by  inputting  other  values 
of  K,  providing  it  with  functional  capabilities  not  specified  in  its  require- 
ments; i.e.,  explicit  specification  of  the  showed  that  the  were  not 
defined  for  possible  values  of  the  input  K.  Although  a similar  question 
could  be  raised  for  values  of  J outside  the  range  0^J<JM,  provision  for 
handling  them  is  not  specified,  for  the  values  of  J are  obtained  from  a 
prior  execution  of  STACK  and  are  not  subject  to  arbitrary  input  by  the 
user. 

The  formal  specifications  are  in  a mathematical  notation  in  order  to 

precisely  define  what  they  mean.  The  G^’s  are  specified  by  listing  the 

variables  involved  and  any  constraints  on  their  ranges;  e.g.,  G^  is  specified 

by  specifying  the  single  value  2 for  the  variable  K,  limiting  the  range  of 

the  variable  I to  the  integer  values  in  the  interval  0 through  IM,  listing 

the  variable  JS  denoting  a stack  of  size  J,  and  limiting  J to  integer  values 

in  the  interval  0 to  JM.  The  functions  F.  are  defined  in  terms  of  their 

J 

allowed  values  and  the  rule  by  which  one  of  the  allowed  values  is  assigned 
to  each  allowed  input  value;  e.g.,  F^  is  a collection  of  three  output 
values:  J'  an  integer  value  denoting  the  number  of  items  in  the  stack 
at  the  end  of  the  computation  of  F^  and  constrained  to  values  in  the  range 
JS(J')  the  value  of  the  top  item  in  the  stack,  and  a message  to 
the  user  stating  a value  has  been  added  to  the  stack.  The  assignment  rule 
is:  J’  is  one  plus  the  input  value  J,  the  value  assigned  to  JS(J')  is  the 
input  value  I,  and  the  message  "VALUE  .^DED"  is  printed  for  all  computations 
initiated  by  an  input  from  G^. 

Before  writing  the  program,  the  input  domain  partition  specifications 
should  be  examined  to  ensure  that  they  completely  specify  all  possible 
inputs.  This  is  done  by  listing  all  variables,  noting  the  maximum  range 
of  each  one  allowed  by  the  computer  (usually  limited  by  the  word  length) , 
and  noting  whether  the  G^  cover  all  possible  values  within  those  ranges. 

J 

For  STACK,  the  input  variables  are  K,  I,  JS,  and  J.  Values  of  K in  the 
inter’/al  1 through  5 are  covered  by  G,  ” i ‘hovers  all  values  of 
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K less  than  1 or  greater  than  5 up  to  the  limits  of  one  computer  word  length 
(no  multiple  precision  computation  is  involved  in  STACK) . Values  of  I in 
the  interval  0 through  IM  are  covered  by  Gj^,  G^,  and  G^.  Values  of  I less 
than  0 and  greater  than  IM  are  covered  by  G2  and  G^.  Both  K and  I are 
defined  as  integer  values.  Any  non-integer  values  supplied  as  inputs 
should  be  truncated  to  integer  values,  if  the  compiler  enforces  the  type 
specification.  JS,  the  stack  data  structure,  is  specified  for  all  sizes 
J of  the  stack  from  0 through  JM  by  G^  and  Gg.  Since  it  is  not  specified 
by  any  G^  for  J greater  than  JM  or  J less  than  0,  a potential  incomplete 
situation  exists;  however,  since  JS  and  J are  both  products  of  prior 
executions  of  STACK  and  are  not  supplied  externally,  this  potential 
incompleteness  should  cause  no  problems. 

In  other  studies  relating  to  verifiable  software.  Investigators  have 
developed  formal  specifications  in  terms  of  assertions  written  in  modified 
predicate  calculus  or  in  a record-like  format  called  Pamas  specifications. 
These  approaches  to  formal  specifications  have  tended  to  be  more  abstract 
than  the  specification  of  STACK  given  here  and  the  question  of  completeness 
of  the  specifications  generally  has  been  ignored.  There  is  a need  for  a 
language  for  writing  formal  specifications.  Such  a language  should  have 
a precisely  defined  syntax  and  semantics  in  order  that  users  of  it  can 
know  exactly  what  the  statements  in  the  language  are  specifying  and  it 
should  be  computer  processable  to  permit  the  use  of  automated  tools  in 
working  with  the  specifications. 

4.4  Functional  Redundancies 


Examination  of  the  11  F 


j 


s shows  that: 


• F 


r . 
0 


hence  there  are  functional  redundancies  present  in  the  formal  specifica- 
tion as  it  is  derived  from  the  informal  requirements  specification.  They 
can  be  removed  by  defining: 

f 

G,  » G2  U G^  : K » 1 or  2,  I < 0 or  I > IM 

t 

Gy  ■ G^  U Gg  : K ■ 3 or  4,  J • 0 


-52- 


This  reduces  Che  number  of  input  data  partitions  and  their  associated 
functions  to  9;  hence  the  program  STACK  can  be  constructed  so  as  Co  have 
9 executable  logic  paths. 

4.5  Branch  Expressions  Specifying  Partition  Constraints 

The  next  step  is  to  write  the  branch  expressions  specifying  the 
partition  constraints  in  Che  programming  language  chosen  for  the  program. 

In  this  case  FORTRAN.  The  preceding  steps  are  independent  of  Che  programm- 
ing language  used. 


(K.EQ.l).AND. 

(I.GE.O) . 

AND. 

(I.LE.IM) 

((K.EQ.l).OR. 

, (K.EQ.2)) 

.AND 

.((I.LT.O) 

.OR. 

.(I.GT.IM)) 

(K.EQ.2).AND. 

.(I.GE.O). 

AND. 

(I.LE.IM)  . 

AND, 

.(J.LT.JM) 

(K.EQ.2) .AND. 

(I.GE.O) . 

AND. 

(I.LE.IM) . 

AND. 

(J.EQ.JM) 

^6*- 

(K.EQ.3).AND. 

, (J.GT.O) 

((K.EQ.3).0R. 

,(K.EQ.4)) 

.AITO 

.(J.EQ.O) 

Gg.*  (K.EQ.4)  .A1TO.(J,GT.0) 

G^qZ  (K.EQ.5) 

G^j^:  (K.LT.l)  .OR.  (K.GT.5) 

Branch  expressions  constraining  J within  its  range,  0 - sJM,  are  not  listed, 
for  in  accordance  z/ith  the  assumption  stated  in  the  preceding  section  that  J 
is  assigned  values  only  by  execution  of  STACK.  Values  of  J will  be  adeauatelv 

I 

constrained  by  G^  and  G^,  which  recognize  J having  a value  at  a range  bound- 
ary, and  by  and  F^,  which  do  not  allow  its  value  to  go  outside  the  range. 


Design  of  the  program  is  aided  by  representing  the  branch  expressions 
in  FP  notation: 


sj  : K.EQ.k 

$2  : I.GE.O 

: I.LE.IM 

: J.LT.JM 
4 

: J.GT.O 


Ir.  terms  of  these  symbols,  the  branch  expression  constraints  for  the 

G.  can  be  written: 

J 


V 

gJ:  (sJ.OR.S^)  (S^.OR.sJ) 

‘=3--  5^55^3=4 

<=6=  ^5 

G^:  (sJ.OR.sJ)  sj 


■=10  = 


'll- 


s’f^^.OR.S^’’^ 

i.  1 


In  this  example,  all  of  the  branch  expressions  are  tests  made  directly 
on  input  variables.  If  transformations  on  these  variables  had  been  necessary 
before  applying  a test,  segments  defining  those  transformations  would  need 
to  be  constructed. 
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4 . 6 Segment  Sequences  Specifying  Functions 


The  next  step  is  to  develop  algorithms  for  computing  the  functions  F. 
and  code  these  algorithms.  In  this  example,  the  algorithms  are  simple  and 
are  given  in  the  definitions  of  the  . Therefore  this  step  involves 
defining  the  segment  sequences  specifying  each  F^ . 


The  program  will  be  designed  for  batch  execution,  with  tape  input 
and  output,  on  the  Cyber  174  at  TRW.  The  input  tape  is  assigned  device 
number  5;  the  stack  JS  and  number  of  elements  J are  stored  on  a tape 
assigned  device  number  7;  the  output  tape  is  assigned  device  number  6. 


Since  the  first  action  of  the  program  is  to  read  the  input  values, 
the  first  code  segment  is: 


• READ  (5,  INPUT) 


The  remainder  of  the 
specification  of  the 
to  compute  them. 


segments  are  developed  by  examining  the  formal 
Fj's  in  order  and  developing  the  code  necessary 


.S2:  J=1 

.S^:  JS(J)=I 

.S, : REWIND  7 
4 

WRITE  (7)J,JS 
.S^:  PRINT(990) 

990  F0R2IAT  (IHl,  13STACK  CREATED) 

.S,:  PRINT(991) 
o 

991  FORIIAT  (IHl,  IIRANGE  ERROR) 
.S^:  REWIND  7 


READ  (7)  J,  JS 


The  F 


•SgC  J-J+1 

•Sg:  PRINT  (992) 

992  FORMAT (IHl,  IIHVALUE  ADDED) 

print  (993) 

993  FORMAT  (IHl,  lOHSTACK  FLXL) 

.S^^:  J-J-1 

.5^2*  P^^NT  (994) 

994  FORJIATdHl,  13HVALUE  RE>JDVED) 
PR^NT  (995) 

995  FORMAT  (IHl,  IIHSTACK  EMPTY) 
PRINT(996) 

996  F0RMAT(1H1,5X,6HJS(J)-,I5) 
•S^^:  PRINT(997) 

997  FORMAT  (1H1,5X,2HJ-,I5) 

.S^^:  PRINT  (998) 

998  FORMAT  (1H1,12HOPTION  ERROR) 

.S^2-  STOP 


are  then  expressed  in  terms  of  sequences  of  the  S. 


’^1"  ^1^2^3^4^5 


•^2=  V6 


• F^:  Sj^S^SgS^S^Sg 


•"4=  V7S1O 


'^6-- 

•^7-- 

^1^7^13 

•^8  = 

' ^1^7^15 

r 

11' 

' ^1^16 
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4.7  Designing  the  Proeram 


From  the  list  of  the  Sj  sequences  for  the  branch  expression  constraints 
of  the  Gj  auid  the  list  of  the  segment  sequences  specifying  the  , a functional 
program  can  be  designed.  It  is  apparent  that  a functional  program  can  be 
written  by  using  the  compound  branch  expressions  associated  with  each 
G,  as  the  subjects  of  IF  statements  with  a TRUE  evaluaticn  branching  to  the 
segment  sequence  specifying  the  corresponding  F^ • Such  a program,  however, 
has  a lengthy  text  and  poor  performance. 

A program  having  economical  text  and  good  performance  can  be  designed  b> 
analyzing  the  branch  expression  sequences  and  segment  sequences.  First  note 

that  segment  appears  in  all  segment  sequences;  therefore  the  program  begins 
execution  with  Next  the  branch  expression  for  G^^^  and  the  segment  seq- 

uences for  F^j^  have  no  common  elements  with  the  other  branch  expression 
sequences;  so  it  simplifies  matters  to  make  that  partitioning  next: 

IFCS^'^^.OR.S^^^)  GOTO  S,, 

11  lo 


A similar  argument  suggests  that  the  branching  for  G^  should  be  performed 
next : 

IFCsJ.OR.sp  goto  (S2.OR.sJ) 

^7 


The  term  "GOTO  (S2.OR.sJ)"  in  the  above  expressions  mean  a transfer  is 
made  to  a statement  later  in  the  code  sequence  containing  "(sJ.OR.sJ)". 

Segment  Sj  follows  the  FALSE  evaluation  of  (S^.OR.sJ)  since  it  is  the  next 
segment  in  the  sequences  for  F^,  F^,  Fg,  and  F^^.  G^^q  and  F^^q  have  no 

common  elements  with  Gg,  G^,  Gg  and  Fg,  F^,  Fg  so  they  are  partititiooed 
ne.xt:  IF  qq^q  3^^ 

The  first  branch  expression  for  G_-viz.  .OR.S^— is  accommodated  as  the 

5 7 i i 

FALSE  evaluation  of  , for  K=*l  and  2 were  separated  fay  an  earlier  test  on  K. 

Thus:  IF  Sg  GOTO 

IF  S^  GOTO  Sj_^ 
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GOTO  S, 


GOTO  S, 


GOTO  S, 


GOTO  S, 


The  processing  for  F^,  F^,  Fg  and  F^q  having  been  accomplished,  the  next 
step  is  to  begin  processing  for  F^,  Fj^,  Fg,  and  F^: 

IF  (Sg.OR.Sg)  GOTO  Sg 
IF  GOTO  S* 


GOTO  S, 


GOTO  S, 


•fg  fg 

Sy  is  Che  same  as  S^,  Che  * denoting  chat  the  GOTO  is  forward  to  not 
backward  to  be  previous  occurrence  of  S^.  The  final  processing  for  Fg,  F^ 
and  F^j^  is: 


IF  GOTO  S, 


-58- 


GOTO 


GOTO 


The  program  design  having  been  created  in  FP  notation,  writing  the 

Ic 

actual  code  involves  only  substituting  the  definitions  of  the  Sj  and 
and  adding  the  non-executable  statements.  The  maximum  allowed  values  of 
J and  I - i.e.,  JM  and  IM,  are  input  in  a data  statement  and  are  chosen, 
arbitrarily,  for  this  example  as  7 and  99,999.  Accordingly,  the  program 
text  is: 

PROGRAM  STACKCINPUT, OUTPUT, TAPE5-INPUT,T.APE6-0UTPUT, TAPE?) 

DIMENSION  JS  (7) 

DATA  JM,IM/7,99999/ 

NAMELIST/INPUT/K,I 
READ (5, INPUT) 

IF((K.LT.l) .OR. (K.GT.5))G0T0  80 

IF(K.LE.2)  GOTO  40 

REWIND  7 

RE.\D(7)  J,JS 

IF(K.EQ.5)G0T0  30 

IF(J.EQ.O)GOTO  10 

IF(K.EQ.4)  GOTO  20 

J-J-1 

RTaIND  7 

WRITE  (7)  J,JS 

PRINT  (990) 

990  FORMAT (1H1,13H VALUE  REMOVED) 

GOTO  90 

10  PRINT  (991) 

991  FORMAT  (IHl ,11HSTACK  EMPTY) 

GOTO  90 
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20  PRIOT  C992)JS(J) 

992  FORMAT  (1H1,5X,6HJS(J)-,I5) 

GOTO  90 

30  PRIOT  (993)  J 

993  FORMAT  (1H1,5X,2HJ-, 15) 

GOTO  90 

40  IF  ((I.LT.O).OR.(I.GT.IM))  GOTO  50 
IF  (K.EQ.2)  GOTO  60 
J-1 

JS(J)-I 
REWIND  7 
WRITE  (7)  J,JS 
PRINT  (994) 

994  FORMAT  (IHl,  13HSTACR  CREATED) 

GOTO  90 

50  PRINT  (995) 

995  FORMAT  (IHl,  IIHRANGE  ERROR) 

GOTO  90 

60  REWIND  7 

READ  (7)  J,JS 

IF  (J.EQ.JIl)  GOTO  70 

J-J+1 

JS(J)-I 

RBJIND  7 

WRITE  (7)  J,JS 

PRINT  (996) 

996  FORMAT  (IHl.llHVALUE  ADDED) 

GOTO  90 

70  PRINT  (997) 

997  FORMAT  (IHl.lOHSTACK  FULL) 

GOTO  90 

80  PRIirr  (998) 

998  FORMAT  (IHl,  12H0PTI0N  ERROR) 

90  STOP 

END 

In  the  substitutions  for  S^,  S^,  S^,  and 

the  last  digit  of  the  99X  label  of  the  FORMAT  statements  was  reassigned 
to  allow  an  orderly  Increase  In  the  label  numbers. 
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4.3  V7riting  a Functional  Program  Containing  Loops 


The  programs  analyzed  in  Section  3 and  the  one  written  using  FP 
techniques  in  4.1  - 4.6  contain  no  loops.  How  FP  concepts  are  extended  to 
deal  with  loops  is  illustrated  by  developing  a sort  routine  called  "INSORT”. 
Two  versions  of  INSORT  are  developed,  one  containing  ordinary  loops  and  the 
other  containing  a DO  loop.  ^Thereas  the  STACK  program  described  in  the 
preceding  section  was  developed  as  an  independently  running  batch  program, 
INSORT  is  developed  as  a subroutine;  i.e.,  it  obtains  its  inputs  from  the 
calling  program  and  its  outputs  are  made  available  to  the  calling  program. 

The  informal  requirements  specification  for  this  subroutine  is: 

• INSORT  is  required  to  sort  the  first  N values  of  a sequence  of 
integer  values  into  descending  order. 

The  formal  specification  for  INSORT  begins  with  definition  of  the 
input  variables,  their  types  and  their  ranges: 

• IN  denotes  an  arbitrary  M-tuple  of  integer  values.  Repetitions 
of  integer  values  are  permitted  in  the  X-tuple. 

• IN  (J)  denotes  the  Jth  element  of  the  M-tuple. 

• M denotes  an  integer  value  representing  the  maximum 
number  of  integer  values  sorted  by  INSORT. 

• J denotes  an  integer  value  in  the  range  l^J^M* 

• The  values  assigned  to  IN  (J)  can  range  over  the  set  of 
integer  values  fitting  within  one  computer  word  length. 

• N denotes  an  integer  value  representing  the  number  of  values  in 
IN  to  be  sorted. 

The  G.  and  F.  may  then  be  snecified: 

J J 

• G^:  N<1  or  M>M  F^:  Range:  L=0,  denoting  an  admissible 

value  of  N. 

Assignment  Rule:  For  all  values  of 
N in  G^ , L=0. 
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• G^:  ^2:  Range:  L>1,  denoting  an  admissible 

value  of  N. 

Assignment  Rule:  For  all  values  of 
N in  G2,  L-1.  No 
sort  required,  only 
1 value  to  be  sorted. 

• G^:  l<Nj<M,  IN  F^:  Range:  L-1,  IN^,  and  K-tuple  of 

Integer  values  IN^CJ)  such 
that  l<Nj<M  and  for  all  J In 
l^J^N-1,  IN  (J)_>IN  (J+1). 

Assignment  Rule:  Each  pair  (N,IN) 

In  G^  is  assigned  to 
the  IN^  from  the  range 
of  such  that  for  all 
K in  l^K^N,  there  exists 
a J in  l^J^N,  such  that 
INg(J)-IN(K). 


The  specification  of  F^  given  above  defines  the  integer  sort  function 
sufficiently  well  for  a programmer  to  develop  the  routine  from  it;  however,  F^ 
has  internal  structure  analyzable  using  FF  concepts.  Since  the  F^  range 
specification  applies  to  adjacent  members  of  the  N-tuple  - i.e.,  to  IN^(J) 
and  IN^(J+1)  and  since  the  assignment  rule  involves  only  rearranging  the 
positions  of  the  integers  and  not  changing  their  values,  it  is  of  interest 
to  partition  the  N-tuple  elements  in  accordance  with  application  of  the  F^ 
range  specification.  Because  this  is  a partitioning  of  G^  and  F^,  the 
notation  G^^  and  F^j  is  used.  The  ^3j'®  this  analysis  do  not  compute 
the  final  output  of  the  routine;  they  compute  the  result  of  applying  the 


range  specification  to  the  G^j  inputs.  In  the  F^j  specifications,  IN'(J) 
denotes  the  value  of  the  Jth  element  of  the  N-tuple  after  the  F^j  computation 
has  been  performed  • The  G^^  and  F^j  are  specified  as: 


G^^:  J-1,  IN(1)<IN(2) 


'2^^:  Range:  IN’ (1)>IN' (2) 


Assignment  Rule:  IN'(1)-IN(2) 


IN'(2)-IN(1) 
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• 0^2;  1<J^N-1, 

IN(J)<IN(J+i) 

• 0^3 : 1_<J_<N-1 

EJ(J)>IN(J+1) 


F32:  Range;  IN' (J) >IN' (J+1) 

Assignment  Rule;  IN’ (J)-IN(J+1) 

IN'(J+1)  - IN(J) 

F33;  Range;  IN' (J)^IN' (J+1) 

Assignment  Rule;  IN'(J)-IN(J) 

IN' (J+1)-IN(J+1) 


• 63^;  J-N  F3^;  Range;  IN^ 

Assignment  Rule;  IN^^IN 

From  this  analysis  of  (G3,F3),  an  algorithm  for  computing  values  of 
F3  can  be  constructed  by  setting  J » 1 initially  and  applying  the  F3  range 
specification  to  IN(1)  and  IN(2).  If  the  values  of  IN(1)  and  1N(2)  do  not 
meet  the  specification,  the  input  is  in  63^^  and  F3j^  applied  to  it  inter- 
changes the  values  of  IN(1)  and  IN(2)  so  that  IN(1)  and  IN(2)  now  meet  the 
specification.  The  value  assigned  to  J is  then  increased  by  1.  If  the 
values  of  IN(1)  and  IN(2)  meet  the  specification,  the  input  is  in  ^23* 

F33  applied  to  this  input  leaves  the  values  of  IN(J)  and  IN(J+1)  unchanged. 
The  value  of  J is  then  increased  by  1.  In  either  case  the  value  of  J has 
become  2,  so  the  next  input  is  either  in  G32  or  G33.  If  it  is  in  G32, 

F32  interchanges  the  values  of  IN(2)  and  IN(3).  The  value  of  J must  then 
be  decreased  by  1,  because  the  new  value  of  IN(2)  can  change  its  relation 
to  IN(1).  If  the  input  is  in  G33,  the  values  IN(2)  and  IN(3)  are  not 
changed  and  the  value  of  J is  increased  by  1.  Therefore,  depending  upon  the 
value  of  the  input  inG3,  the  appropriate  assignment  rule  is  applied  and 

J la  subse^ently  Increased  or  decreased  until  J*N,  placing  the  input  in  Sa 

/ 

and  completing  the  sort. 

Translation  of  the  formal  specification  into  a program  design  begins 
by  writing  the  constraints  on  the  input  values  for  each  G^  (and  ^3^)  in 
terms  of  branch  expressions  . Here  again,  the  example  is  illustrated  using 
FORTRAN,  but  any  programming  language  could  be  just  as  easily  used. 


-63- 


(N.LT.l).OR.(N.GT.M) 


• G2:  N.EQ.l 

• G^:  N.GT.l  * IN 

• G^j^:  (J.EQ.1).AND.(IN(J).LT.IN(J+1)) 

• (J*GT.1).AND.(J.LT.N).AND.(IN(J).LT.IN(J+1)) 

• G23:  (J.LT.N).AND.(III(J).GE.IN(J+1)) 

• G^^;  J.EQ.N 

In  the  branch  expressions  defining  the  constraints  on  G33,  the  constraint 
J.GE.l  is  not  given  explicitly,  since  J is  set  equal  to  1 Initially  and 
successive  applications  of  the  will  not  reult  in  J becoming  less 

than  1. 

F?  symbols  are  next  assigned  to  the  branch  expressions. 

• sj;  (N.LT.l).OR.(N.GT.M) 

• 83 : N.EQ.l 

• S3:  J.EQ.l 

• S^:  J.EQ.N 

• S3:  IN(J) .LT.IN(J+1) 
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^ . ^ ^ ___  _ ■___  


• G 


33' 


54  i>5 


The  segments  for  computing  the  ^j*s  (and 
• S, : J-1 


• S2:  K-IN(J) 


IN(J)-IN(J+1) 

IN(J+1)-K 

• S^:  J-J+1 

• S, : J-J-1 

4 

• S^:  L-1 

• S,:  L*0 

6 

• S^:  RETURN 

In  terms  of  these  segments,  the  segment  sequences  for  the  (and  F^j's) 

are: 


• F, 


• F, 


^6  S7 
S5  ^7 


S,  S 

■31 


-S 

• F. 


'32 


• F 


33 


• F 


^2  S3 

S2  S4 


34 


The  program  design  can  now  be  written  in  FP  notation: 


IF  GOTO 


IF  $2  GOTO 


IF  Sj  GOTO  $2 
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IF  S, 

A 

GOTO  S 


IF 

^A 

GOTO  S 


"5 

GOTO  S 


GOTO  S 

k 

5 

GOTO  S 

k 

5 

7 


5 


3 


The  program  text  is  obtained  by  substituting  the  definitions  of  the 
FP  symbols  as  shown  in  Figure  A-2, 


SUBROUTINE  INSORT  (IN,N,M) 
DIMENSION  liUM) 

IF(N.LT.1.0R.  N.GT.M)  GOTO  100 

IF(N.EQ.l)  GOTO  80 

J=1 

30  IF(IN(J).LT.IN(J+1))  GOTO  50 
AO  J-J+1 

IF(J.EQ.N)  GOTO  80 
GOTO  30 
50  K=IN(J) 

IN(J)-IN(J+1) 

IN(J+1)-K 
IF(J.EQ.l)  GOTO  AO 
J-J-1 

’ GOTO  30 
80  L=1 

GOTO  200 
100  L=0 

200  RETURN 
END 


Figure  A-2.  INSORT  without  DO  Loop 


k k 

In  the  diagram  of  Figure  4— 3«y  has  been  replaced  by  its  complement  S^! 

J.NZ.l  to  avoid  crossing  of  lines.  The  lines  looping  back  from  S,  and 

k k k ^ 

to  have  an  arrow  at  their  end  to  Indicate  the  direction  of  the 

transfer,  all  other  transfers  being,  by  convention,  downward. 

The  paths: 

• ^1  ^6  ^7 

• L^i  S2  Sj 

executed  for  N<1  and  N"l,  respectively,  are  non-looping  paths.  For  N-2, 
there  are  two  paths  that  go  directly  through  the  program  without  looping: 

• h'-  4 h 4 h 4 h =7 

• ^5  =2  =5  S3  Sj  S5  S3 

In  Lj,  Sj  constrains  the  inputs  to  those  values  such  that  IN(1)^IN(2);  in  L^, 
Sj  constrains  the  inputs  to  those  values  such  that  IN(1)<IN(2). 

All  other  e:tecution  sequences,  occurring  for  N>2,  involve  at  least 
one  of  the  loop  sequences: 

S s'”  S S S^’  S S 

^5  ^3  ^4  ^3’  ^5  ^2  ^3  ^3  ^4  ^5’  ^5  ^2  ^3  ^4  ^5’ 

The  possible  execution  sequences  for  N>2  can  be  analyzed  into  3 cases: 

• The  input  IN(J)  is  already  sorted  into  order,  defining 
execution  sequences,  one  for  each  value  of  N,  in  which 
is  always  evaluated  FALSE. 

• L,:  sf  S,  s!  S,  sf  S,  sf  S-  S,  ; N-3 

0 121o34534o7 

sf  si  S5  S3  si  S3  S3  Sj  S3  S3  si  S3  S^  : N-4 


sf  si^  S,  s!  S-  sf  S-  sf  si  s.  sj  s,  s, 

121j34o  453457 

These  sequences  involve  only  the  first  loop. 
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• The  input  value  IN(1)  is  greater  than  or  equal  to  the  value 
of  IN(J)  for  all  J in  1<J^N,  but  those  values  of  IN(J)  are 
not  in  descending  order. 


• ^6' 


s'  s'  s^  s'  S3  s'  s'  S3  s'  S4  si  S3  si  $1  S3  s'  S5  s, 

'2  h 4 h 'J  4 h 4 ^5  '2  '3  '4  '5  '3  4 '3  '4  '5 ' 


In  this  set  of  execution  sequences,  the  sequence  S,  S,  will  never 
k 

occur,  for  can  never  be  evaluated  TRUE  when  J)*l. 

• All  other  inputs. 

• h-  ^1  ^2  sj  S3  sf  s|  S2  si  S2  S3  si  si  S3  s 


These  sequences  contain  all  3 loop  sequences. 

Each  of  these  sets  (L^,  Lg,  L^)  of  sequences  corresponds  to  a 
recursively  defined  function  (F^,  Fg,  F^,  respectively);  therefore  an 
association  of  a set  of  inputs,  a set  of  sequences,  and  a function  is 
defined  for  these  three  cases;  i.e.,  the  triples: 


«3,  L..  Fj) 


^^6'  ^6’ 


• (G^,  L^,  F,) 

are  defined.  Because  of  this  association,  one  nay  call  L^,  Lg,  and 
"logic  paths",  neaning  by  a logic  path  a set  of  executable  sequences 
composed  of  the  same  segments  and  branch  expressions  and  associated  with 
a recursive  function  F^  defined  on  a domain  . 

Note  that  in  handling  loops  the  F?  concepts  were  applied  at  two 
levels:  first  to  analyze  the  structure  of  F3  and  second  to  partition  G3 
and  F3  into  the  5 partitions  (G3,  L3,  F3) , (G^,  L^,  F^) , (G^,  L^,  F-), 

j 


'6 


Fg) , and  (G^, 


L.,,  F,).  This  shows  how  a function  F^  defined  by 


-7,  *7 

Che  requirements  on  a program  may  have  internal  structure. 
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ft 


4.9  Writing  a Functional  Program  Containing  a DO  Loop 


Since  the  looping  part  of  the  IJISORT  Program  is  entered  after  setting  J-l 
and  is  exited  when  J»N,  it  may  be  contained  in  a DO  loop.  In  FORTRAN,  a 
DO  loop  of  the  form; 

DO  30  J-1,  N 


30  CONTINUE 

executes  by  setting  J initially  to  the  value  1 and  executing  In  sequence  the 
statements  following  the  DO  statement  until  the  statement  labeled  30  Is 
reached.  Then  the  value  of  J Is  Increased  by  1 and  execution  continues 
with  the  statement  immediately  following  the  DO  statement.  This  activity 
continues  until  the  value  of  J becomes  greater  than  N,  whereupon  the  loop 
is  exited  with  execution  continuing  with  the  statement  immediately  following 
the  labeled  statement  30. 


Tlie  logic  of  the  FORTRAN  DO  loop  can  be  expressed  in  FP  notation  by 

denoting  the  labeled  statement  terminating  the  DO  loop  by  S.  and  the  DO 

k ^ 

statement  by  DO  S . . Here  the  superscript  k denotes  the  value  of  the  index 

J k 

of  the  DO  loop  (in  the  case  of  INSORT,  the  value  of  J) . Evaluation  of  Sj 

denotes  executing  the  terminal  statement,  increasing  the  value  of  the  index 

by  1,  comparing  the  new  value  of  the  index  with  the  value  of  the  upper  limit 

in  the  DO  statement,  and  transferring  to  the  statement  immediately  following 

DO  S.  unless  the  new  value  of  the  index  exceeds  the  upper  limit,  in  which 

J k 

case  execution  proceeds  with  the  statement  following  . 

Thus  INSORT  can  be  rewritten  to  contain  a DO  loop  having  an  index  J. 
Eicecution  of  the  DO  loop  will  cause  J to  be  set  initially  equal  to  1 and  be 
incremented  automatically  by  1 until  J>N1II  at  which  time  execution  continues 
with  the  statement  following  the  DO  loop.  Since  DO  loop  semantics  do  not 


allow  the  value  of  J to  be  changed  within  the  DO  loop,  the  decrease  in  the 
value  of  J called  for  in  the  case  (^22^  cannot  take  place  inside  the  DO 
loop;  consequently  the  sort  algorithm  must  be  changed,  so  that  evaluating 
S^  branches  outside  the  DO  loop.  The  interchange  of  elements  specified  by 
S-  is  then  executed  and  the  DO  loop  exeuction  is  started  over  from  the 

^ It 

beginning,  J-1.  Denoting  the  terminal  statement  of  the  DO  loop  by  S^  then 
leads  to  the  following  expression  of  the  sort  algorithm  in  FP  notation: 
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DO  S4 

IF  GOTO  $2 

GOTO  Sj 
^2 

GOTO  DO 


and  the  revised  sort  program  in  FP  notation  Is: 


IF  GOTO  S. 
1 0 

IF  S2  GOTO  Sj 
V 

DO  S, 

4 

IF  Sj  GOTO  S2 
GOTO  Sj 


GOTO  DO 


GOTO 


leading  to  the  program  text: 

SUBROUTINE  INSORT  (IN,N,M) 
DIMENSION  IN(M) 

IF((N.LT.l).OR.(N.GT.M))  GOTO  100 
IF  (N.EQ.l)  GOTO  80 
mi  = N-1 

30  DO  40  J-1,  NMl 

IF(IN(J) .LT.IN(J+1))  GOTO  50 

40  CONTINUE  

GOTO  80 
50  K=IN(J) 

IN(J)  = IN(J+1) 

IN(J+1)  = K 
GOTO  30 
80  L-1 

GOTO  200 
100  L-0 

200  RETURN 

END 
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This  version  of  INSORT  will  run  slower  than  the  first  version  because 
it  always  returns  to  the  beginning  (J>1)  of  the  list  of  integers  after  an 
interchange  of  two  list  members  has  been  made. 


The  first  two  paths  of  this  version  are  the  same  as  for  the  ocher 
version  because  they  do  not  pass  through  Che  DO  loop. 


• L 

• L 


l‘ 

2* 


Si  Sg  S^ 

4 ^7 


For  N^2,  Che  paths  involve  Che  DO  loop  sequences.  They  can  be  analyzed  as 
two  cases: 


The  input  IN(J}  is  already  in  descending  order,  defining  e-cecution 
sequences  in  which  S^  ia  always  evaluated  FALSE. 


s[  s^  sj  s^  si  S5  S7 


f f 1 f 2 f 3 
H h ^4  S5  S4  S^  S5  S^ 


: N-2 

; N-3 


’f  f 1 f 2 f 
S S S S S S 
1 2 4 ^5  4 ^5 


S S 

^5  ^4  ^5  ^*7 


N-M 


The  input  IN(J)  is  not  in  descending  order,  defining  the  following 
execution  sequences. 

• ‘•4'  4 =2  =4  ^5  ^2  =4  4 =4  S =7 

fflt  If2f3 
^1  ^2  si  S3  S,  S,  S.  S,  S3  S,  S3  S, 

^1  ^2  S4  S3  $2  S3  S^  S3  S2  S3  S^  S3  S^  S3  Sy 

sf  S^  S^  S^  S^  S S^  S^  S^  S^  s q 

1 ^2  S4  S3  S^  S3  S2  S3  S^  S3  S^  S3  S- 


Thus  with  Che  DO  loop,  the  execution  sequences  can  be  partitioned  into  2 
sets,  each  set  composed  of  members  containing  the  same  segments  and  branch 
expression  evaluations. 
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5.0  TESTING  FUNCTIONAL  PROGRAMS 


The  earliest  thinking  about  FP  was  largely  motivated  by  testing  concerns. 
In  recent  years,  attempts  to  apply  engineering  discipline  to  software  testing 
have  brought  about  increased  attention  to  thoroughly  testing  a program’s 
structural  components.  Most  recently  this  trend  has  extended  to  the  desire, 
if  not  the  requirement,  to  identify  and  test  each  and  every  program  logic 
path  at  least  once  in  the  resting  process.  For  small  and/or  simple  programs, 
this  objective  can  usually  be  reached  with  relative  ease.  For  large  and/or 
very  complex  programs,  however,  the  large  number  of  logic  patlis  and  the 
often  complicated  conditions  associated  with  executing  a specific  path 
together  pose  overwhelming  difficulty  with  which  the  tester  must  cope.  In 
appreciation  of  the  need  for  both  reduced  cost  and  increased  rigor  of  test- 
ing, much  effort  has  been  devoted  to  research  and  development  of  very 
sophisticated  tools  to  help  the  tester  identify  program  logic  paths  and 

develop  program  Inputs  (i.e.,  test  cases)  to  force  their  execution.  The 

3 4 5 

use  of  such  tools  (e.g.,  the  Automated  Test  Data  Generator  ’ * developed 
by  TRW  for  NASA/JSC)  in  support  of  testing  even  small  (but  relatively 
complex)  FORTRAN  programs  has  made  it  clear  that  a good  deal  of  the  testing 
effort  can  be  wasted  in  looking  for  inputs  to  force  the  execution  of  phan- 
tom paths.  Moreover,  a program  containing  8 executable  logic  paths  to  do 
the  "functional"  work  of  two  generally  requires  more  analysis  and  computer 
resources  for  testing  than  is  actually  necessary. 


FP  directly  addresses  these  problems  in  several  ways.  First,  as  seen 
in  the  preceding  examples  of  Routine  A and  B,  FP  yields  programs  of  reduced 
logical  complexity,  containing  only  those  logic  paths  needed  to  supply 
unique,  explicitly  required  processing  capabilities.  Second,  application 
of  FP  establishes  and  maintains  the  mapping  between  subsets  the 

input  domain,  functions  required  to  operate  on  in  Gj , and  the 

logic  paths  (Lj)  which,  when  coded  and  executed,  perform  the  intended 
function  on  the  specified  inputs.  Clearly,  the  implication  of  FP,  at 
least  with  respect  to  exercising  all  program  logic  paths,  is  strong  and 
encouraging  for  those  truly  concerned  with  the  cost  and  rigor  of  testing 
software. 
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The  following  discussion  Illustrates  the  primary  benefits  of  FP 
with  respect  to  testing.  These  benefits  include: 

• reduced  difficulty  in  selecting  input  values  for  program  test 
cases,  and 

• reduced  difficulty  in  defining  a set  of  test  cases  to  thoroughly 
exercise  program  structure 

They  are  presented  in  the  context  of  sample  FORTRAN  programs,  however,  as 
with  other  aspects  of  FP,  the  concepts  and  techniques  can  be  readily  gen- 
eralized to  other  languages  and  applications  and  the  above  benefits  should 
be  even  more  pronounced  for  larger  and  more  complex  programs. 


5.1  Testing  Routine  A 


We  tackle  Routine  A first  to  demonstrate  that,  even  for  very  simple 
programs,  the  question  of  what  it  takes  to  achieve  a thorough  test  may  not 
be  easy  to  answer.  The  original  version  of  Routine  A listed  in  Section  2.3 
was  tested  prior  to  the  time  that  It  was  rewritten  as  a functional  program. 
The  programmer  was  required  to  devise  those  tests  necessary  to  execute 
each  branch  at  least  once  and,  without  much  difficulty  found  four  test 
cases  that  satisfied  this  requirement.  They  are: 


Case  1 : GN»0 
CN»5 
CT=4 
TR«6 

Case  2 : GN**0 

CN=3 
CT=4 
TR=6 

Case  3:  GN“1 
CN=8 
CT-4 
TR=6 

Case  4:  GN“1 
CN=»5 
CT-4 
TR=6 


The  values  assigned  to  the  integer  variables  JA,  JB,  JD,  JE,  and  JV  were 


the  same  for  all  4 test  cases  and  are  not  listed  here. 


These  test  cases  reflect  the  modus  operandl  of  most  testers  - viz., 
to  construct  one  test  case  and  then  construct  the  remaining  cases  by 
changing  the  values  of  the  minimum  number  of  variables.  Comparing 
these  test  cases  with  the  input  domain  partitions  developed  in  the  FP 
analysis  of  Routine  A shows  that  each  test  case  belongs  to  a different 
input  domain  partition  G.  and  the  test  case  set  provides  a test  for  each 
of  the  partitions  in  the  original  version  of  Routine  A. 

The  actual  formulation  of  the  required  tests  involved  tracing  through 
the  flow  diagram  (or  the  code)  and  noting  the  branching  actions  which 
were  directly  controllable  by  the  assignment  of  input  values.  Thus,  it 
is  not  surprising  that  the  description  of  the  test  cases  (above)  is  much 
like  that  of  the  input  domain  partitions.  That  is,  if  the  testing  ap- 
proach had  been  to  simply  select  a single  test  case  from  each  subset  of 
the  input  domain,  then  the  set  of  test  cases  thus  derived  would  have  been 
equivalent  to  the  actual  test  cases  developed  by  the  programmer.  Case 
1,  an  input  from  G^,  makes  no  use  of  the  value  assigned  to  TR;  case  2, 

, makes  no  use  of  the  values  assigned  to  TP,  JA,  JB,  JD,  JE,  and  JV; 
case  3,  G^,  makes  no  use  of  the  value  assigned  to  CT;  and  case  A,  G^ , 
makes  no  use  of  the  va.ues  assigned  to  CT,  JA,  JB,  JD,  TE,  and  JV. 

On  the  other  hand,  the  final  version  of  the  functional  program  (Sec- 
tion 2.7)  was  developed  using  a compound  conditional  branch  expression 
which,  upon  evaluation,  would  choose  between  the  two  distinct  functions 
to  be  performed. 

This  latter  version  of  the  program  corresponds  to  the  merged  input 

f 

domain  subsets  G,  ■ G,UG.  and  G'  “G.  U G,.  Notice  that  one  method  of 
1 1 3 2 2 4 

deriving  test  cases  (i.e.,  simply  sampling  once  from  each  subset  G'^  and 
G’^)  yields  two  test  case  sets,  as  follot^s: 

Set  1:  (GN^^O,  CN^TR)  or  (G:^-0,  CN>:CT)  , JE,  JD,  JA,  JB,  JV 

Set  2:  (GNfiQ,  CN<TR)  or  (GN-0,  CN<CT) 

In  contrast,  if  one  attempts  to  devise  test  cases  that  will  exhaust 
ail  of  the  logical  possibilities  for  the  evaluated  branch  expression. 
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l.e. 

((GN.EQ.O).AND.(CI.LT.CT).OR. (GN.NE.O).AND.(CN.LT.TR))  then  it  is 
possible  to  specify  eight  distinct  test  case  sets,  as  follows: 


Set 

1: 

QJ-O, 

CN^CT, 

CN<TR, 

JE, 

JD, 

JA, 

JB  1 

JV 

Set 

2: 

Ql-0, 

CNSCT, 

CN3TR, 

JE, 

JD, 

JA, 

JB ) 

JV 

Set 

3: 

GN^^O, 

CN<CT, 

CN2XR, 

JE, 

JD, 

JA, 

JB  9 

JV 

Set 

4: 

GNf^O, 

CNSCT, 

CN5TR, 

JE, 

JD, 

JA, 

JB, 

JV 

Set 

5: 

OJ-O, 

CN<CT, 

CN<TR 

Set 

6: 

GN-0, 

CN<CT, 

CNSTR 

Set 

7: 

OlT^O, 

CN<CT, 

CN<TR 

Set 

8: 

CN2CT, 

CIKTR 

A more  careful  analysis  of  the  compound  boolean  expression,  however, 

r 

shows  that  the  combination  (GN*0,  CN^CT)  causes  the  left  half  of  the 
expression  to  be  ''FALSE”  and  the  right  half  of  the  expression  to  be 
"FALSE"  (because  GN  0 is  "FALSE")  independent  of  the  relationship  bet- 
ween CN  and  TR.  Thus,  Set  1 and  Set  2 are  logically  equivalent  and  can 
be  combined  and  represented  as: 

Set  1'  : GN-0,  CNaCT,  JE,  JD,  JA,  JB,  JV 

Similar  arguments  hold  for  Set  3 and  4,  S and  6,  and  7 and  3: 

Set  3'  : GNj-sQ,  CNaTR,  JE,  JD,  JA,  JB,  JV 
Set  5'  : GN-0,  CN  < CT 

Set  7"  : GN;e  0,  CN<  TR 

Finally,  looking  again  at  G'^  and  G'^  aad  at  the  two  test  cases  sampled, 
the  need  for  a Set  la  and  lb  and  a Set  2a  and  2b  is  indicated  by  the 
presence  of  the  "or"  in  both  domain  definitions  and  test  case  specifi- 
cations. Notice  that  the  three  separate  attempts  to  derive  Routine  A 
test  cases  eventually  produced  sets  of  four  cases,  such  that: 

Case  1 is  a member  of  Set  I'sSet  lb 

Case  2 is  a member  of  Set  5'sSet  2b 

Case  3 is  a member  of  Set  3*3  Set  la 

Case  4 is  a member  of  Set  7'^  Set  2a 
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5.2  Testing  the  Triangle  - TvTae  - Determination  Program 

In  a prior  investigation^  of  an  approach  and  a tool  (the  Product 
Assurance  Confidence  Evaluator,  PACE)  used  to  assure  thorough  structural 
testing  of  programs,  a small  program  written  to  "determine  whether  three 
integers  representing  three  lengths  constitute  an  equilateral,  isosceles, 
or  scalene  triangle  or  cannot  be  the  sides  of  any  triangle"  was  used  as  an 
example.  The  problem  was  said  by  Fred  Gruenberger^  to  be  a dandy  one  for 
teaching  logic  and  flowcharting  as  well  as  program  testing.  In  particular, 
he  reported  that  "even  the  good  students  are  astonished  to  find  that  it 
takes  more  than  six  cases  to  make  a thorough  test ". 

As  part  of  an  investigation  of  alternative  measures  of  testing 
thoroughness,  a programmer  was  given  the  problem  statement  and  asked  to 
write  a Triangle-Type-Determination  program.  Figure  5-1  presents  a listing 
of  the  FORTRAN  source  code  developed  by  the  programmer.  The  segments  of 
the  program  are  identified  in  the  left  margin,  and  the  program  logic  is 
illustrated  in  Figure  5-2,  showing  the  logical  branching  potential  between 
the  segments.  From  Figure  5-2  one  can  quickly  identify  88  "apparent" 
paths  through  the  program,  but  it  is  not  so  easy  to  tell  which  and  how  many 
paths  are  actually  executable.  As  it  turns  out,  only  11  of  the  paths  can 
be  executed,  and  the  remaining  77  are  phantom  paths.  Reference  3 further 
demonstrated  the  need  for  5 separate  test  cases  to  cause  all  executable 
statements  to  be  exercised  and  11  cases  to  execute  every  transfer. 
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100 
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992 
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993 
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NAMELI ST / INPUT / I , J , K 
READ  (5,  INPUT) 

MATCH  = 0 

IF  (I.EQ.J)  MATCH  = MATCH  + 1 

IF  (I.EQ.K)  MATCH  - MATCH  + 2 

IF  (J.EQ.K)  MATCH  - MATCH  + 3 

IF  (MATCH. EQ.O)  GO  TO  500 

IF  (MATCH. EQ.l)  GO  TO  400 

IF  (MATCH. EQ. 2)  GO  TO  300 

IF  (MATCH. EQ. 3)  GO  TO  100 
WRITE  (6,901) 

FORMAT  (IHl,  IIHEQUILATERAL) 

GO  TO  900 

IF  (J+K.LE.I)  GO  TO  600 
WRITE  (6,902) 

FORMAT  (IHl,  9HIS0SCELES) 

GO  TO  900 

IF  (I+K.LE.J)  GO  TO  600 
GO  TO  200 

IF  (I+J.LE.K)  GO  TO  600 
GO  TO  200 

IF  (I+J.LE.K)  GO  TO  600 

IF  (J+K.LE.I)  GO  TO  600 

IF  (I+K.LE.J)  GO  TO  600 

TOITE  (6,903) 

FORMAT  (IHl,  7HSCALENE) 

GO  TO  900 
WRITE  (6,904) 

FORMAT  (IHl,  14HNOT  A TRIANGLE) 

STOP 

END 


Figure  5-1  : FORTRAN  Listing  of  Triangle-Type-Determination  Program 
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:e  of  Triangle  Program 
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We  now  consider  a more  functional  version  of  the  triangle-type- 
determination  program  and  investigate  the  need  for  test  cases  to  achieve 
equivalent  testing  thoroughness.  From  case  analysis,  we  can  see  that 
there  are  two  basic  outcomes  possible:  1)  Triangle  and  2)  Not-a-trlangle, 
Outcome  2 should  be  obtained  If,  for  three  positive  Integers  I,J,  K it  Is 
determined  that  the  length  of  one  "side"  Is  greater  than  or  equal  to  the 
sum  of  the  other  two.  That  Is, 

I+JsK  or  I+KSJ  or  J+K  s I—Not-a-triangle 

For  Outcomel,  there  are  three  subcases,  namely: 

1.1  I>J>K  (All  sides  equal)  — Equilateral 

1.2.1  I - Jj-sK 

1.2.2  I ^ JsK  (Exactly  2 sides  equal)  Isosceles 

1.2.3  I - 

1.3  I ^ J and  and  (No  sides  equal)  Scalene 

The  functional  program  listed  in  Figure  5-3  differs  from  the  earlier 
version  in  one  major  respect.  That  is,  the  original  program  contained  logic 
paths  corresponding  to  three  extraneous  cases,  namely: 

• Equilateral  Non-triangle 

• Isosceles  Non-triangle 

• Scalene  Non-triangle 

Although  this  distinction  Is  neither  required  by  the  problem  statement  nor 
immediately  obvious,  the  logic  necessary  to  distinguish  is,  nevertheless, 
embedded  in  the  program.  These  extra  paths  may  be  of  little  or  no  importance 
to  the  user  of  the  program,  but  to  someone  required  to  read  and  understand, 
maintain  or  test  the  program,  the  paths  require  extra  analysis  and  can 
(in  the  case  of  large  and/or  complex  programs)  make  Che  job  much  more  diffi- 
cult than  it  has  to  be. 
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NAMELIST / INPUT/ I , J , K 
READ  (5,  INPUT) 


IF  (I+J.LE.K)  GO  TO  400 
IF  (I+K.LE.J)  GO  TO  400 
IF  (J+K.LE.I)  GO  TO  400 


IF  (I.EQ.J)  GO  TO  100 

IF  (J.EQ.K)  GO  TO  200 

IF  (I.EQ.K)  GO  TO  200 

WRITE  (6,901) 

FORMAT  (IHl,  7HSCALENE) 

GO  TO  900 

IF  (J.EQ.K)  GO  TO  300 

WRITE  (6,902) 

FORMAT  (IHl,  9HISOSCELES) 

GO  TO  900 
WRITE  (6,903) 

FORMAT  (IHl,  IIHEQUILATERAL) 

GO  TO  900 
WRITE  (6,904) 

FORMAT  (IHl,  14HNOT  A TRIANGLE) 

STOP 

END 


Figure  5-3  : Functional  Triangle  Program 

The.  logical  branching  potential  of  this  functional  version  of  the 
program  Is  Illustrated  graphically  In  Figure  5-4.  As  expected,  there  are 
eight  distinct  logic  paths  (L^) , they  are  easy  to  Identify,  and  all  are 
possible  to  execute  (l.e.,  there  are  no  phantom  paths).  It  Is  also  fairly 
easy  to  see  that  It  Is  necessary  to  execute  each  path  at  least  once  In 
order  to  execute  each  and  every  branch  In  the  program.  Thus  we  need  eight 
test  cases  to  achieve  testing  thoroughness  equivalent  to  that  obtained  with 
eleven  test  cases  for  the  non-functlonal  version.  More  Important,  however. 
Is  the  ease  with  which  the  appropriate  test  cases  can  be  specified. 

Figure  5-5  lists  the  seg.-nent-to-segment  sequence  for  each  path  together 
with  the  logical  conditions  on  the  Inputs  which  cause  the  path  to  be  taken 
and  the  composite  conditions  which  comprise  the  specification  of  the  Input 
domain  partition. 


Code  Sequence 

s,  sf  s,  sl[  sf  Sc  s5  S„  S, 

112345626 


Si  sf  s'  s'  s'  s'  s'  S3  s, 
Si  s[  s'  s'  s'  s'  S3  s^ 


Si  s'  s'  s'  sj  s'  S3  s,. 
s,  sf  s,  sl^  s,  s, 

11234746 

^ =2  ®3  =6 

*1  *2  S =6 

=1  S =6 


Logical  Conditions 

I+J>K,  I+K>J,  J+K>I, 
I/J,  J?«K,  Ii^K 

Same  as  #1  except  I=K 

I+J>K,  I+K>J,  J+K>I, 

1 ^ J,  J=K 

Same  as  it3  except  I=J 
Same  as  //4  except  J ^ 
I+J>K,  I+K>J,  J+K^I 
I+J>K,  I+K£J 
I+J<K 


s = 

(I+J>K) 

(I+K>J) 

(J+K>I) 

(I  J 

K ^ 

I)} 

s = 

(I+J>K) 

(I+K>J) 

(J+K>I) 

(1  J ^ 

K = 

I)} 

s = 

{I,J,K; 

(I+J>K) 

(I+K>J) 

(J+K>I) 

il  ^ J = 

K)} 

"4  = 

(I+J>K) 

(I+K>J) 

(J+K>I) 

(I  = J 

K)} 

s = 

(I+J>K) 

(I+K>J) 

(J+K>I) 

(I  = J = 

K)} 

s = 

{I,J,K; 

(I+J>K) 

(I+K>J) 

(J+K^I) } 

^7  = 

(I+J>K) 

(I+K£J) } 

-I.J.K; 

(I+J<K) } 

Figure  5-5  : Triangle  Program  Paths 


and  J K 
K 
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5.3  Testing  the  Stack  Program 


To  further  investigate  the  testing  of  functional  versus  non-functional 
programs,  several  versions  of  the  STACK  program  (Section  4.2)  were  developed 

Q 

and  analyzed  by  the  Automated  Test  Data  Generator  (ATDG)  . Although  ATDG 
was  originally  developed  by  TRW  to  support  the  rigorous  testing  of  software 
at  the  NASA  Johnson  Space  Center,  its  capability  of  producing  path-related 
test  cases  made  its  applicability  to  functional  programs  especially  inter- 
esting. 

The  ATDG  analyzes  source  code  elements  (e.g.,  subroutines),  identifies 
conditional  transfers,  and  generates  a set  of  paths  containing  all  of  these 
transfers.  By  application  of  powerful  loathematical  techniques,  the  number 
of  paths  required  to  cover  all  transfers  is  minimized.  Supplementary  in- 
formation is  also  provided  by  ATDG  to  support  derivation  of  actual  test 
input  data  to  execute  the  paths. 

Within  ATDG,  a rather  elaborate  algorithm  is  Included  for  the  sole 
purpose  of  avoiding  the  generation  of  unexecutable  (i.e.,  phantom)  paths. 

Since  functional  programs  contain  no  phantom  paths,  it  was  expected  that 
ATDG  resulting  test  cases  would  correspond  to  the  previously  defined  function- 
al test  cases.  In  each  Instance,  the  ATDG-generated  cases  (i.e.,  those 
required  to  exercise  all  conditional  transfers  at  least  once)  corresponded 
exactly  to  those  designed  to  test  all  functions®.  Finally,  a rough  com- 
parison was  obtained  for  the  ATDG  execution  time  required  for  the  function- 
al versions  of  STACK  versus  that  required  for  similar  (i.e.,  approximately 
the  same  size  and  logical  complexity)  but  non-functional  programs.  The 
execution  time  was  substantially  less  for  the  functional  STACK  programs, 
and  this  is  most  likely  attributable  to  the  lack  of  time  required  to 
process,  recognize  and  discard  phantom  paths. 


In  completing  the  STACK/ATDG  experiment,  it  was  recognized  that  an 
important  relationship  exists  between  the  fundamental  concepts  underlying 
FF  and  ATDG.  This  relationship  is  based  on  the  fact  that  ATDG  (and  related 
technologies  like  symbolic  execution  and  program  proving)  attempt  to  gen- 


erate and  work  with  one  (or  more)  path(s)  for  each  of  the  G.  as  defined  in 
Section  2.2.  It's  natural  to  conclude  that  such  a tool  could  be  very  use- 


ful as  a management  aid  in  analyzing  functional  programs  to  assure  that  none 
of  the  intended  F^  are  inadvertantly  omitted  and  (probably  just  as  important 


but  much  more  difficult  to  detect)  that  no  extraneous  functions  are  Includ- 
ed during  Implementation.  In  addition,  the  tool  could  be  used  to  support 
FP  analysis  of  existing  code  and  aid  In  the  Identification  of  existing 
functions  and  thus  an  understanding  of  current  functional  content. 


6.0  FUNCTIONAL  PROGRAMMING  IMPACT  EVALUATION 


Since  FP  is  a new  way  of  writing  programs,  it  may  be  expected  to  have 
an  Impact  on  programming  language  requirements  and  on  the  reliability  and 
maintainability  of  programs  developed  using  it.  The  results  of  a study  of 
this  impact  are  reported  in  the  following  sections. 


6.1  Impact  on  Programming  Language  Reoulrements 

Although  FP  concepts  are  applicable  whatever  programming  language  is 
used,  the  following  questions  can  be  raised: 


• Are  there  language  features  capable  of  making  functional  programming 
easier? 

• Are  there  programming  standards  - i.e.,  restrictions  on  the  use  of 
language  features  - that  would  make  functional  programming  easier? 


FP  partitions  the  input  domain  E into  the  subsets  Gj  associated  with 
logic  paths  Lj  and  functional  capabilities  F^ . It  therefore  focuses  on  the 
inputs.  A programmer  writing  a program  should  accordingly  have  a clear 
picture  of  the  input  variables,  the  values  assignable  to  them,  and  how  the 
ranges  of  the  variables  are  partitioned  to  form  the  G^ . Most  programming 
languages  do  not  aid  the  programmer  in  clearly  defining  the  Inputs  to  the 
program  he  is  writing.  Generally,  input  variables  may  appear,  for  the  first 
time,  anywhere  within  a program  and  in  many  programming  languages  - e.g., 
FORTRAN  - a programmer  does  not  have  to  explicitly  declare  an  input  variable 
unless  he  wishes  to  restrict  its  range  to  a set  of  values  different  from 
that  defined  by  a computer  word. 

Visibility  of  the  input  domain  would  be  aided  by  requiring  that  all 
input  variables  be  declared  at  the  beginning  of  a program.  EUCLID,  e.g., 
requires  a program  to  list  all  the  identifiers  input  into  a procedure. 

Partitioning  of  the  input  domain  is  specified  using  branch  expressions, 
^ince  F?  associates  an  input  domain  partition  G^  with  an  executable  logic 
path  Lj , visibility  of  that  association  is  often  improved  through  use  of 
compound  branch  expressions.  Thus,  facilities  to  aid  the  writing  of  com- 
pound branch  expressions  and  their  consistent  and  efficient  interpretation 
could  contribute  strongly  to  the  writing  of  functional  programs. 


-86- 


Structured  programming  has  been  successfully  Introduced  into  tnany  pro- 
gramming groups  by  expressing  it  in  terms  of  a few  simple  rules  - viz., 
restricting  code  structural  elements  to: 

• in-line  code  segments 

• IF  A THEN  B ELSE  C 

• DO  S WHILE  A 

• DO  S UNTIL  B 

Since  these  rules  are  relatively  simple,  programmers  can  easily  learn  to 
follow  them.  Are  there  similar  rules  for  FF  that  can  be  just  as  easily 
learned  and  followed? 

That  question  can  be  investigated  by  using  FP  notation  to  analyze 
differences  between  FP  and  structured  programming.  As  originally  proposed 
by  Dijkstra,  structured  programming  is  essentially  writing  a program  in  the 
form: 

• IF  S^  THEN  ELSE 

IF  S2  THEN  ELSE  C22 

IF  S^  THEN  C , ELSE  C ^ 

n nl  n2 

In  this  representation  of  a structured  program,  S^  represents  a branch 
expression  and  and  C^2  represent  executable  code  segments  containing 
the  allowable  code  structure  elements.  This  form  of  the  program  code 
provides  a linear  structure.  It  can  be  read  sequentially;  i.e.,  the  code 
in  line  i is  executed  before  the  code  in  line  i+1.  Dijkstra  sought  by  this 
means  to  obtain  increased  visibility  of  program  structure  from  the  program 
text,  an  objective  of  FP,  too.  This  linear  structure  does  improve  struc- 
tural visibility  over  oldir  methods  of  programming  because  it  eliminates 
the  complex,  often  convoluted  branching  present  in  many  programs;  however, 
as  noted  in  functional  programming  analysis  of  structured  programs,  it  can 
also  encourage  the  formation  of  phantom  paths  and,  in  the  process,  obscure 
both  structural  and  functional  visibility. 

F?  can  be  compared  with  structured  programming  by  looking  closely  at 
a functional  program  in  its  simplest  form: 
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• IF  THEN 

ELSE  IF  S2  THEN 

ELSE  IF  S^  THEN 

ELSE  IF  THEN  C 
n n 

In  this  representation  of  a functional  program,  Sj^  represents  the  branch 

expression  which  upon  TRUE  evaluation  initiates  execution  of  the  logic  path 
t k. 

L^  “ S-  ; Sp  represents  the  branch  expression  which  upon  TRUE  evaluation 
i i i z ^ 

initiates  execution  of  the  logic  path  3^^  S2  C2;  and  so  on.  represents  an 
executable  code  segment,  possibly  containing  DO  structures.  In  this  form,  a 
functional  program  is  a structured  program  in  which  C^2  represented  by 
Cf,  C22  is  represented  by  C2,  etc. 

The  problem  in  this  form  of  functional  program  is  the  code  redundancy 
generally  occurring  in  the  C^;  i.e.,  the  code  sequences  in  each  of  the 
generally  will  have  subsequences  repeated  in  two  or  more  C^.  This  leads  to 
writing  more  lines  of  code,  potentially  resulting  in  more  errors,  and  a 
requirement  for  more  computer  resources  (storage  and  time)  to  process  the 
program.  As  is  shown  in  sections  3 and  4,  programs  can  be  designed  to 
eliminate  all  or  most  of  the  code  redundancy,  while  retaining  the  functional 
property  of  no  phantom  paths.  Therefore  a requirement  for  a language  to  aid 
in  the  writing  of  functional  programs  is  to  provide  facilities  for  specify- 
ing in  a compact,  visible  way  the  intended  execution  sequence  of  code 
segments  for  each  C^. 

6.2  Impact  on  Software  Reliability 

FP  was  developed  to  aid  the  production  of  reliable  programs.  Has  it 
achieved  this  goal?  The  following  evidence  supports  the  conclusion  that  FP 
does  contribute  to  producing  more  reliable  programs: 

• Rewrite  of  programs  originally  written  using  conventional  programm- 
ing methods  (see  Section  3)  generally  results  in  programs  having 
fewer  statements  (as  much  as  50%  fewer  in  the  case  of  Routine  A). 
The  fewer  statements  means  that  fewer  characters  and  words  have  to 
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be  written,  resulting  generally  in  fewer  typographical  errors. 

The  shorter  program  text  also  makes  the  text  easier  to  read  and 
comprehend  increasing  the  probability  that  a programmer  will  spot 
an  error  that  has  been  made  and  correct  it  before  the  program  goes 
into  use. 


• Since  in  a functional  program  all  paths  are  executable,  it  is 
relatively  easy  to  trace  a path  through  the  program  mentally 
executing  the  path  and  assuring  one's  self  that  program  operation 
will  proceed  as  intended. 

• Since  a program  written  using  FP  methodology  will  have  its  function- 
al requirements  - i.e.,  the  (G.,F  ) - defined  before  the  code  is 

^ J 

written  and  since  the  executable  logic  paths  L are  constructed  to 

^ j ^ 

correspond  to  the  functional  requirements  possible 

to  mentally  compare  the  code  of  logic  path  with  its  associated 
functional  requirement  and  by  that  process  detect  errors  in  the 
code. 

« Since  the  for  a functional  program  are  explicitly  defined,  it 
is  relatively  easy  to  design  test  cases  to  demonstrate  satisfaction 
of  functional  requirements  - viz.,  select  an  from  each  G^  - 
assuring  verification  of  all  functional  requirements. 

The  preceding  arguments  are  theoretical,  stating  what  should  happen. 

An  empirical  argument  is  obtained  from  the  experience  with  the  STACK  program 
(see  Section  4.8).  STACK  was  written  using  FP  methodology  - i.e.,  defining 

A A 

the  functional  requirements  (G  ,F.)  first  and  then  designing  the  program  to 

J 1 A A 

have  logic  paths  L.  corresponding  to  the  (G.,F  ).  That  program  was  tested 
J J J A 

functionally,  designing  test  cases  by  choosing  from  each  Gj . Test  cases 

for  each  functional  requirement  were  executed  and  all  executed  correctly, 

supporting  a conclusion  that  with  a high  probability  there  were  not  errors 

in  STACK  as  it  was  originally  written.  Although  this  is  only  one  case  and 

the  absence  of  detectable  errors  could  be  fortuitous,  the  results  of  STACK 

testing  support  the  conclusion  that  FP  contributes  to  producing  reliable 

programs. 
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b. 3 Impact  on  Software  Maintenance 


Software  maintenance  - solving  of  problems  occurring  In  operational 
use  of  a program  and  adapting  a program  to  a changing  operational  environ- 
ment - Is  one  of  the  largest  components  of  life  cycle  cost.  FP  can  Impact 
software  maintenance  In  several  ways: 

• By  contributing  to  production  of  more  reliable  programs,  FP 
reduces  the  number  of  problems  maintenance  programmers  have  to 
solve  and  hence  reduces  maintenance  cost* 


• FP  produces  a description  of  a program  - viz.,  the  functional 

A A 

requirements  association  of  each  functional  require- 

ment with  an  executable  logic  path  and  functional  capability  - that 
a maintenance  programmer,  who  was  not  Involved  In  developing  the 
program,  can  use  to  understand  the  program  and  to  solve  problems*  E.g. 
a software  problem  generally  can  be  associated  with  a specific  Input 
or  a specific  set  of  Inputs.  From  this  input,  the  FP  program  descrip- 
tion readily  aids  associating  the  problem  with  a specific  , F^ , 
and  Lj.  From  examination  of  the  problem  evidence  and  the  , F^ , 

Lj  descriptions,  the  source  of  the  problem  can  be  more  quickly  identi- 
fied and  the  problem  solved  at  less  than  usual  expense* 


• If  the  problem  is  elusive,  the  FP  description  can  aid  the  design 
of  test  cases  to  make  the  problem  more  visible. 

• Once  the  source  of  a problem  is  identified,  the  FP  description 
aids  identification  of  the  code  to  be  modified. 


• A new  operational  requirement,  if  it  is  functional  in  nature,  can 

A A 

be  expressed  in  the  form  (Gj,F^).  This  defines  the  functional 
requirement  precisely.  This  form  of  the  requirement  when  added 
to  the  FP  description  of  the  program  will  show  immediately  whether 
the  new  requirement  is  a modification  of  an  old  requirement  or 
whether  it  is  a completely  new  requirement.  With  the  revised  set 
of  functions,  the  modifications  to  the  code  necessary  to  Implement 
the  revisions  are  easily  designed  and  the  test  cases  needed  to 
verify  the  implemented  revision  can  be  readily  constructed* 
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• If  the  new  operational  requirement  is  a performance  requirement, 
generally  it  can  be  related  to  certain  of  the  functional  require- 
ments - e.g.,  to  speed  up  execution  of  function  Fj  - and  the  FP 
description  can  aid  finding  the  code  to  be  modified  to  fine  tune 
program  performance. 


7.0  SYSTEM  LEVEL  FUNCTIONAL  PROGRAMMING 

The  concepts  of  FP  were  developed  and  applied  initially  at  the  routine 
level.  Programs  are,  however,  collections  o£  routines  and  software  sub- 
systems and  systems  generally  are  collections  of  programs  and  routines. 

Thus  FP  concepts  can  also  be  applied  at  those  levels,  for  a routine  is 
connected  to  another  routine  by  having  its  output  Fj (E^)  serve  as  the  input 

E to  the  connected  routine  where  it  initiates  executlc..  of  logic  path  L, 
m K 

specifying  function  Fj^  and  resulting  in  output  Fj^(E^). 

Thus  execution  of  two  connected  routines  results  in  composition  of  the 
functions  specified  by  the  individual  routines.  This  composition  can  be 
extended  to  the  subsystem  and  system  level. 


Taken  as  a whole,  the  software  for  a fire  control  system  specifies  a 
function.  That  function  generally  will  be  analyzable  into  functions  F^ 
corresponding  to  specific  functional  requirements.  A particular  functional 

A A 

requirement  (G  , F.)  may  define  the  fire  control  rules  corresponding  to  a 
specific  combat  situation  while  another  functional  requirement  will 

define  the  functional  requirement  corresponding  to  another  combat  situation. 
It  is  equally  possible  to  envision  FP  application  at  the  system  level  in 
terms  of  a computer  operating  system.  Here  the  inputs  are  things  such  as 
application  programs,  files,  and  machine  resources.  Outputs  are  things 
such  as  initiation  of  execution  of  a program  and  execution  of  a service,  a 
distinct  function  of  the  operating  system.  The  complete  requirements  for 
an  operating  system  can  be  defined  by  specifying,  for  each  operating 
system  service,  its  domain  and  the  function  F^  to  be  performed. 
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8.0  TOOLS  TO  SUPPORT  FUNCTIONAL  PROGRAMMING 


Although  the  concepts  of  functional  programming  are  relatively  simple, 
application  of  them  can  Involve  considerable  analysis,  writing,  and  book- 
keeping. The  tedious  nature  of  these  chores  may  inhibit  the  use  of  the 
methodology.  Accordingly,  tools  need  to  be  developed  to  automate  the 
manual  effort  required  and  to  reduce  possibilities  for  human  error. 

An  Informal  preliminary  requirements  specification  for  a tool  (FPA)to 
support  functional  programming  analysis  of  existing  programs  is: 

• FPA  is  required  to: 

• Read  the  text  of,  for  example,  a JOVIAL  (J3)  program  and 
identify  each  branch  expression  and  in-line  code  segment 
in  the  program. 

• Assign  to  each  branch  expression  a symbol  S(J,K),  with  J 
denoting  an  integer  value  representing  the  numerical  order 
of  Che  branch  expression  in  Che  program. 

• Assign  to  each  in-line  code  segment  Che  symbol  S(J) , with 
J denoting  an  integer  value  representing  the  numerical 
order  of  Che  segment  in  Che  program. 

• Produce  a listing  of  the  program  annotated  to  show  in  the 
left  hand  margin  a symbol  S(J,K}  for  each  line  of  code 
containing  a branch  expression,  with  Che  integer  J in  the 
symbol  denoting  the  numerical  order  of  Che  branch  expression 
and  to  show,  also  in  the  left  hand  margin,  a symbol  S(J)  for 
each  line  of  code  beginning  an  in-line  code  segment. 

If  a line  of  code  contains  both  a branch  expression  and  the 
beginning  of  a code  segment,  the  branch  expression  symbol 
shall  be  printed  first  followed  by  a comma  and  the  segment 
symbol  printed  to  the  right  of  the  comma. 

• List  all  branch  expression  symbols  and  their  corresponding 
branch  expression  in  the  format  - the  branch  expression 
symbol  followed  by  a colon  followed  by  the  branch  expression. 

• List  all  in-line  code  segment  smbols  and  their  corresponding 
segments  in  the  format  - the  segment  symbol  followed  by  a 
colon  followed  by  the  segment. 
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• List  all  Input  variables  - l.e.,  variables  to  which  values 
must  be  assigned  in  order  for  the  program  to  be  executed 
and  any  data  declarations  involving  those  variables. 

• Print  the  program  in  FP  notation. 

Such  a tool  would  greatly  ease  the  job  of  analyzing  existing  programs, 
producing  an  annotated  listing,  a listing  of  the  branch  expression  and 
segments,  and  a listing  of  the  program  in  FP  notation. 


Another  tool  (FPS)  to  support  the  writing  of  functional  programs  has  the 
following  informal  preliminary  requirement  specification: 

• FPS  is  required  to: 

• Accept  as  Input,  the  name  of  each  input  variable  and  its 
range. 

• Accept  as  input,  specifications  on  input  domain  partitions 
in  the  form  of  branch  expressions. 

• Accept  as  input,  specifications  on  the  functions  associated 

with  each  input  domain  partition  - viz.,  a specification  of 
the  range  of  each  function  and  a specification  of  the  rule 
assigning  to  each  input  in  a value  Fj (E^)  in  the  range 

set. 


• List  the  name  of  each  input  variable,  followed  by  its  range 
specification. 

• List  the  specifications  of  the  input  domain  partitions  in 
the  format  - followed  by  a colon  followed  by  the  branch 
expressions  defining  the  partition  and  a listing  of  any 
input  variables  belonging  to  Gj  but  not  partitioned. 

• List  the  specifications  for  the  functions  corresponding  to 
each  input  domain  partition  in  the  format  - followed  by 
a colon  followed  by  the  range  set  specification  and  F, 


■j 

followed  by  a colon  followed  by  the  assignment  rule  specifica- 
tion. 


• Check  the  input  variable  ranges  against  the  ranges  speci- 
fied in  each  input  domain  partition.  Print  any  variables 
whose  range  is  not  completely  covered  in  the  input  domain 
partition  specifications  and  identify  the  portion  of  the 
range  not  covered. 

Such  a tool  would  assist  in  maintaining  the  functional  requirements 
and  in  identifying  any  missing  requirements. 


9.0  CONCLUSIONS  AND  RECOMMENDATIONS 


At  the  outset  of  the  contractual  project  effort  reported  here, 
functional  programming  (FP)  was  little  more  than  a gleam  in  the  eye  of  the 
authors.  To  be  sure,  several  applications  of  FP  analysis  to  some  small 
routines  had  been  accomplished  and  the  results  (l.e.,  improved  understand- 
abllity,  reliability  and  performance)  were  particularly  encouraging.  The 
ultimate  goal  then  was  to  extend  the  scope  of  applications,  investigate 
both  the  potential  capabilities  and  limitations  of  the  FP  techniques,  and, 
where  appropriate,  refine  and  add  to  the  techniques  as  necessary  to  form 
a disciplined  and  comprehensive  yet  practically  useable  programming 
methodology.  The  more  realistic  goal  of  our  initial  study  was  to  invest 
limited  time  and  resources  necessary  to  concentrate  on  key  issues  whose 
resolution  should  and  will  play  a major  role  in  the  future  evolution  and 
acceptance  of  FP  as  an  integral  part  of  improving  software  engineering 
practice.  With  completion  of  the  subject  study  and  this  report  of  key 
findings,  the  latter  goal  has  been  reached  and  substantial  progress  toward 
the  ultimate  goal  has  been  achieved. 

Still,  the  FP  methodology  as  defined  and  demonstrated  in  this  report 
is  in  its  infant  stage.  For  example,  we  have  shown  that  in  every  sample 
application  it  was  possible  to  carefully  analyze  a computer  program  and 
revise  the  logical  structure  so  that  the  resulting  program's  functional 
content  could  be  more  readily  discerned  than  that  of  the  original,  non- 
functional version.  In  some  cases  the  Improvement  has  been  dramatic 
(in  terms  of  reduced  number  of  distinct  logic  paths),  but  in  others  only 
minor  Improvements  were  possible.  In  short,  we  have  been  able  to  show 
that  in  most  cases  we  should  be  able  to  effect  some  improvement  in  the 
functional  visibility  of  computer  programs,  but  we  have  yet  to  prove  that 
we  can  do  so  in  all  instances. 

Similarly,  we  have  f.  rmulated  a sequence  of  eight  basic  steps  to  be 
taken  in  developing  a functional  program  from  scratch.  In  this  study, 
nowever,  we  have  gone  no  further  than  to  demonstrate  (by  way  of  varied 
examples)  that  the  procedure  accurately  implements  the  FP  principles  and 
that  a good  programmer  can  (with  only  d little  training)  actually  follow 
the  procedure  in  successful  development  of  functional  programs. 
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One  of  the  najor  results  of  the  FP  study  was  to  further  confinn  the 

hypothesis  that  time  and  effort  spent  in  rigorously  (i.e.,  complecely  anc 

precisely)  specifying  software  requirements  leads  to  marked  reductions  in 

the  usual  problems  and  costs  of  life  cycle  software  development,  test, 

9 10 

operation  and  maintenance.  ’ In  fact,  we  observed  from  one  experiment 
(the  development  of  multiple  versions  of  the  stack  creation  and  maintenance 
program)  that  if  the  original  program  requirements  are  written  "functionally" 
(i.e.,  in  terms  of  distinct,  required  functions  corresponding  to  distinct 
subdomains  of  possible  values  of  program  inputs) , then  It  is  almost  impossi- 
ble to  design  and  Implement  anything  other  than  a functional  program  to  do 
the  job.  As  a consequence,  a very  high  degree  of  traceability  (from  re- 
quirements to  code)  is  achieved,  and  this  traceability  directly  contributes 
to  eliminating  ordinary  problems  owing  to  differing  interpretations  and 
omissions  due  to  oversights. 

At  this  stage  in  the  evolution  of  a more  rigorous  and  disciplined 
software  development  process,  many  new  techniques  have  been  proposed  and 
some  have  been  heavily  advertised  as  a panacea  for  the  past  problems  of 
software  production.  Understandably,  they  who  have  experienced  and/or 
paid  for  the  problems  in  the  past  are  eager  to  find  new,  more  effective 
methods  that  can  help  to  eliminate  similar  problems  in  the  future.  Such 
a climate  can  be  very  good  or  very  bad  with  respect  to  the  development, 
application,  refinement  and  eventual,  cost-effective  utilization  of  any 
particular  new  technique.  For  instance,  if  one  makes  great  claims  about 
the  potential  of  a technique  (in  order  to  get  a lot  of  people  to  try  it 
out),  it  is  possible,  in  fact,  likely  that  the  technique  will  ( in  actual 
practice)  fail  to  live  up  to  the  claims.  On  the  other  hand,  if  no  claims 
are  made  it  can  be  difficult  to  get  the  attention  of  those  who  can  pre- 
Eumablv  use  and  benefit  from  the  technique.  In  either  case,  the  two  things 
“hat  are  most  needed  (lots  of  experimental  application*?  in  carefully  ccn- 
culled  situations  followed  by  objective  evaluation  of  not  only  current 
capabilities  and  limitations  but  also  the  probable  and  possible  capabilities 
achievable  through  continued  development  and  refinement)  will  not  be  forth- 
coming. The  result;  an  otherwise  sound  and  very  promising  new  technique 
night  die  before  it  ever  really  gets  off  the  ground. 


-97- 


■ 


We  hope  for  and  expect  a nicer  fate  for  Functional  Programming.  We 
have  tried  in  this  report  to  make  only  those  claims  for  which  we  have 
reasonable  supportive  evidence  of  their  validity.  At  the  same  time  we  are 
careful  to  point  out  that,  although  our  limited  experiences  with  F?  have 
all  been  positive  and  encouraging,  we  see  the  need  for  a great  deal  more 
experimentation  and  study  and  still  more  experimentation  before  the  full 
potential  of  FP  can  be  brought  effectively  to  bear  on  a wide  variety  of 
software  development  activities.  It  is  worth  noting  that  It  has  taken  about 
eight  years  and  much  study  for  structured  programming  to  grow  from  newly 
proposed  and  only  slightly  understood  principle  to  commonly  accepted  and 
widely  used  modern  programming  practice.  We  suggest  that  the  time  has  come 
to  give  strong  attention  to  the  outstanding  problems  that  still  plague 
developers  and  users  of  software  and  to  invest  appropriate  time  and  energy 
to  bring  about  an  accelerated  maturation  of  FP  principles  and  methodology. 

If  we  really  work  at  it,  we  can  probably  be  producing  truly  reliable  and 
highly  maintainable  software  long  before  another  eight  years  has  passed  us 
by. 

During  the  course  of  the  FP  study,  many  reference  documents  were 
reviewed  and  many  discussions  were  held  with  people  currently  working  at 
advancing  a variety  of  software  development  and  test  technologies,  including: 
software  requirements  engineering,  structured  programming,  automated  test 
data  generation,  symbolic  program  execution  and  program  proving.  The 
overall  outcome  of  this  investigation  of  other  technologies  has  been  to  ex- 
pose the  existence  of  very  strongly  related  objectives  and,  in-  some  cases, 
almost  identical  techniques.  For  example,  we  found  that  in  completing  a FP 
analysis  (as  defined  in  this  report)  we  were  actually  accomplishing  the 
basic  steps  and  deriving  the  necessary  Information  required  for  automated 
generation  of  test  data.  Moreover,  it  was  found  that  those  who  are  deep  into 
symbolic  execution  and  program  proving  are  fully  as  Interested  in  the  actual 
functional  content  of  program  paths  and  are  fully  as  frustrated  by  un- 
warranted program  complexity  as  we  are  in  attempting  a thorough  FP  analysis. 
Among  all  these  technologies,  the  dominant  common  thread  is  a particularly 
strong  interest  in  striving  (whether  by  constructive  techniques  as  in  FP, 
analytical  approaches  as  in  symbolic  execution  and  program  proving,  or 
actual  execution  and  evaluation  of  test  results)  to  remove  any  and  all 
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differences  between  functional  requirements  (l.e.,  what  the  software  needs 
to  do)  and  functional  capabilities  (l.e.,  what  the  software  actually  does). 
This  close  tie  between  technologies  Is  fortunate.  In  Chat  concerted  re- 
search and  development  leading  to  new  breakthroughs  in  any  one  area  Is 
almost  certain  to  yield  related  advances  In  others.  For  example,  continued 
refinement  and  broad  application  of  FP  can  lead  to  production  of  programs 
having  a much  smaller  number  of  logic  paths  Chan  might  otherwise  be  Che 
case,  and,  as  a direct  result.  It  should  be  possible  to  complete  path-by- 
path proofs  of  much  larger  programs  Chan  any  attempted  to  date. 

Based  on  the  above  consideration.  It  Is  recommended  Chat  we  not  only 
continue  needed  research  Into  Che  fundamentals  of  software  structure  (In 
general)  and  F?  constructive  techniques  (In  particular) , but  also  that  we 
maintain  Che  fullest  possible  understanding  of  ongoing  research  and  new 
advances  In  related  technology  areas.  A comprehensive  research  program 
should  Include: 

• continued.  Iterative  application  and  refinement  of  the  F?  methodo- 
logy documented  In  this  report, 

• special  studies  of  the  Impact  of  evolving  FF  methodology  on  ocher 
technologies, 

• investigation  (through  experimental  application)  of  Che  feasibility 
and  merit  of  applying  FP  principles  in  the  writing  of  formal  system 
and  software  requirements  specifications, 

• detailed  design.  Implementation  and  experimental  application  of  the 
FP  analysis  and  FP  support  tools  specified  in  this  report  and 
continued  analysis  of  Che  type  and  extent  of  support  obtainable 
from  existing  Cools  (e.g.,  compilers,  text  editors,  automated  test 
data  generators  and  symbolic  execution  systems) , and 

• study  of  new  advances  In  other  technology  areas  (e.g.,  improved 
network  analysis  and  path  representation  techniques,  development  of 
more  easily  proven  programming  constructs  and  language  features,  and 
program  test  measurement  and  reliability  assessment/prediction 
technology)  and  subsequent  Incorporation  of  appropriate  new  technology 
as  integral  elements  of  the  FP  methodology. 

If  the  needed  research  and  development  Is  carried  out.  It  Is  highly 
likely  that  FP  will  become  an  important,  constructive  element  of  future 
software  engineering  discipline  and,  perhaps  more  importantly,  we  should 
achieve  unprecedented  synergism  among  previously  distinct  (and  not  altogether 
cooperative)  software  technologists.  If  so,  we  may  begin  to  reap  the  real 
rewards  of  truly  advanced  software  production  technology  much  sooner  than  one 
might  expect. 
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